Inventario de software con Win32_Product en Windows

Gestionar el inventario de software en Windows es una de esas tareas que casi nadie quiere hacer, pero que tarde o temprano toca afrontar, sobre todo cuando administras varios equipos o tienes que dejar unos portátiles “limpios” para producción. En este contexto, la clase WMI Win32_Product suele aparecer como la opción rápida y directa para consultar aplicaciones instaladas, automatizar desinstalaciones y validar instalaciones basadas en MSI.

Sin embargo, apoyarse en Win32_Product sin entender bien qué hace por debajo puede generar sorpresas desagradables: desde tardanzas enormes en los scripts, hasta reparaciones silenciosas de paquetes MSI. Además, no todo el software se instala mediante Windows Installer, y eso complica el inventario y la desinstalación automatizada. En las siguientes secciones veremos con detalle cómo usar Win32_Product, qué alternativas hay en PowerShell y en el registro, cómo obtener GUID de productos, y cómo ejecutar scripts de forma segura y eficaz en entornos Windows modernos.

Qué es Win32_Product y qué información de software proporciona

La clase WMI Win32_Product forma parte del espacio de nombres root\cimv2 de WMI y está diseñada para representar los productos instalados mediante Microsoft Windows Installer (MSI). Cuando se consulta, permite obtener datos clave de los paquetes MSI presentes en el sistema, como el nombre, la versión, el proveedor o el identificador de producto (GUID), entre otros atributos relevantes para administración.

Entre las propiedades más útiles de Win32_Product destacan el nombre del producto (Name), el número de versión (Version), el fabricante (Vendor), el identificador de producto (IdentifyingNumber) y la ubicación del paquete local (LocalPackage). Estas propiedades resultan especialmente valiosas cuando se necesita inventariar software MSI, comprobar qué versión de una aplicación crítica está instalada o identificar de forma unívoca un producto para desinstalarlo mediante comandos automatizados.

Conviene tener claro que Win32_Product solo devuelve software instalado con Windows Installer. Cualquier programa que se haya instalado con instaladores personalizados, instaladores tipo EXE, aplicaciones empaquetadas de otro modo o software de la Microsoft Store no aparecerá en las consultas de esta clase. Por tanto, aunque es una herramienta potente, no cubre por sí sola todo el inventario de aplicaciones de un equipo.

La documentación técnica de Microsoft remite a recursos como TechNet ScriptCenter para ver ejemplos adicionales de scripts que utilizan esta clase y muchas otras de WMI. En dichos recursos se muestran casos prácticos para enumerar, filtrar, desinstalar y auditar software instalado vía MSI, tanto en equipos locales como remotos, empleando distintos lenguajes de scripting.

Ejecutar scripts WMI para inventario de software

Aunque hoy en día la mayoría de administradores se inclina por PowerShell, todavía hay muchos entornos donde los ejemplos de Microsoft y de documentación clásica se apoyan en VBScript y WMI. Los scripts orientados a inventariar software suelen ejecutarse contra el equipo local, pero con pequeños cambios pueden apuntar a máquinas remotas si se dispone de permisos y conectividad adecuados.

En la guía típica de Microsoft se explica un procedimiento sencillo para ejecutar scripts con extensión .vbs. El flujo general consiste en escribir el código del script, guardarlo con la extensión correcta y ejecutarlo desde la línea de comandos usando cscript, de forma que la salida quede en la consola y no se abra la interfaz gráfica de Windows Script Host.

El proceso básico para lanzar uno de estos scripts pasa por copiar el código de ejemplo, guardarlo en un archivo como nombre.vbs (asegurándose de que el editor no añade “.txt” al final), abrir una ventana de símbolo del sistema, cambiar al directorio donde se ha guardado el script y ejecutar un comando del tipo cscript nombre.vbs. Este enfoque es válido tanto para scripts que solo leen información como para aquellos que realizan acciones como desinstalaciones.

Es importante tener en cuenta los permisos necesarios al acceder a ciertos recursos. Si el script consulta información sensible, como algunos registros de eventos protegidos o áreas del sistema sujetas a Control de cuentas de usuario (UAC), puede que sea imprescindible abrir la consola con privilegios elevados (Ejecutar como administrador) para que funcione correctamente.

Aunque muchos ejemplos se centran en el equipo local, Microsoft documenta en profundidad cómo conectarse a WMI en equipos remotos. Mediante cadenas de conexión que incluyen el nombre del equipo y credenciales con permisos adecuados, es posible recorrer varias máquinas y recolectar información de software de forma centralizada, algo muy útil en auditorías o despliegues masivos.

Desinstalar software MSI usando Win32_Product

Una de las capacidades más llamativas de la clase Win32_Product es que no solo permite listar aplicaciones MSI instaladas, sino también desinstalarlas mediante el método Uninstall. Esto abre la puerta a automatizar la limpieza de software no deseado en decenas de equipos sin tener que recorrer manualmente el Panel de control.

En VBScript, la aproximación típica consiste en conectar al servicio WMI del equipo deseado, lanzar una consulta sobre la clase Win32_Product filtrando por el nombre del producto, y a continuación recorrer la colección resultante invocando el método Uninstall() sobre cada instancia. De este modo, se puede eliminar silenciosamente una aplicación concreta que se haya instalado mediante Windows Installer.

Un script en Visual Basic clásico suele seguir un patrón similar al siguiente: se define el equipo de destino (normalmente “.” para indicar la máquina local), se crea un objeto WMI apuntando a root\cimv2 con el nivel de suplantación apropiado, se ejecuta una consulta “Select * from Win32_Product Where Name = ‘Nombre del producto’” y, por cada objeto devuelto, se llama a objSoftware.Uninstall(). El resultado es que la aplicación especificada se desinstala sin necesidad de interacción manual.

En PowerShell, la lógica es muy parecida pero con una sintaxis más limpia. Se usa Get-WmiObject -Class Win32_Product para recuperar todos los productos MSI, se filtra con Where-Object por el nombre deseado y, en un bucle foreach, se llama al método Uninstall() de cada objeto que coincida. Este enfoque es perfecto, por ejemplo, para eliminar en bloque un paquete corporativo que ya no se desea mantener en el parque de equipos.

Ahora bien, es importante recordar que Win32_Product puede tener efectos colaterales. Cuando se enumeran productos con esta clase, Windows Installer puede desencadenar comprobaciones de estado y reparaciones de paquetes dañados. En entornos de producción grandes, este comportamiento puede generar tráfico, consumo de CPU y retardos considerables, por lo que muchos administradores prefieren otras vías para inventariar software y reservar Win32_Product solo para casos muy concretos de desinstalación controlada.

Uso de PowerShell para listar software instalado

Cuando se trata de obtener una lista de programas instalados, PowerShell ofrece varias alternativas, algunas basadas en WMI y otras apoyadas directamente en el registro de Windows. No existe un único comando perfecto para todos los escenarios, por lo que suele ser útil combinar varias técnicas según el tipo de software que se quiera detectar.

El comando más directo, aunque no siempre el más recomendable, es Get-WmiObject Win32_Product (o su alias “gwmi Win32_Product”). Este comando utiliza WMI para enumerar todos los productos MSI instalados en el sistema. Es muy cómodo porque devuelve objetos ricos en propiedades, pero tiene el inconveniente de las reparaciones que puede provocar y de que deja fuera cualquier programa que no sea MSI.

Para abarcar más software, muchos administradores recurren al registro y a programas para inventarios. Las claves de HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall y su homóloga HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall almacenan información de los programas instalados de 64 y de 32 bits, respectivamente. Con PowerShell se puede ejecutar un comando tipo Get-ItemProperty sobre estas rutas para recuperar valores como DisplayName, DisplayVersion, Publisher o InstallDate.

Un enfoque clásico consiste en usar gp (alias de Get-ItemProperty) sobre ambas rutas y filtrar aquellos elementos cuyo DisplayName no esté vacío. Luego se selecciona únicamente la propiedad DisplayName para obtener un listado rápido de aplicaciones visibles en “Programas y características”. De esta forma se evita depender de WMI y se capturan muchos más instaladores, incluidos los que no están basados en MSI.

Si se necesita información más completa, se suelen construir comandos algo más elaborados que llaman a Get-ItemProperty y después usan Select-Object para mostrar varias propiedades, como el nombre visible, la versión, el fabricante y la fecha de instalación. Finalmente, se aplica Format-Table -AutoSize para que la salida resulte legible en consola. Esto se puede hacer tanto con la rama estándar de 64 bits como con la rama Wow6432Node para cubrir el software de 32 bits.

Otra herramienta disponible es WMIC (Windows Management Instrumentation Command-line), que aunque está en desuso en las versiones más recientes de Windows, todavía se ve en muchos servidores y estaciones de trabajo. Un comando como wmic product get name,version lista los nombres y versiones de los productos MSI, resultando útil cuando se necesita un resultado rápido sin entrar en scripts complejos.

DisplayName, UninstallString y claves de registro para desinstalar

Más allá de WMI, una parte muy importante del inventario de software en Windows se sustenta en el registro. Cada aplicación instalada suele tener una clave dentro de las rutas de Uninstall que mencionábamos antes, y dentro de esa clave se alojan valores que resultan fundamentales tanto para mostrar la aplicación en el Panel de control como para automatizar su eliminación.

Dos de los valores más interesantes que suelen encontrarse en cada entrada son DisplayName y UninstallString. El primero se corresponde con el nombre que se ve en “Desinstalar o cambiar un programa” dentro de “Programas y características” del Panel de control. Es decir, el texto que el usuario reconoce como nombre de la aplicación tal y como la ve en la interfaz gráfica.

El valor UninstallString es aún más jugoso para administración, porque contiene el comando que Windows ejecuta cuando se pulsa el botón de desinstalar desde el Panel de control. Muchas veces es una llamada a msiexec con un GUID y varios parámetros, o bien un ejecutable propio del fabricante con opciones específicas. Conocer esta cadena permite lanzar la desinstalación de forma remota o automatizada desde scripts de PowerShell, VBScript u otras herramientas de gestión.

Si se examinan estas claves con PowerShell usando Get-ItemProperty, se pueden combinar valores como DisplayName, DisplayVersion, Publisher y UninstallString para construir listados completos de aplicaciones con toda la información necesaria para inventario, auditoría y desinstalación. Este enfoque es muy flexible, ya que no depende del tipo de instalador (MSI, EXE, etc.) y no provoca las reparaciones asociadas a Win32_Product.

A nivel visual, todo esto se refleja en la ventana de “Desinstalar o cambiar un programa” que encontramos en Programas y características. Cada línea de esa lista suele corresponder a una entrada de registro en las rutas mencionadas, con un DisplayName y normalmente un UninstallString asociado. Entender esta relación ayuda a diagnosticar por qué a veces una aplicación no aparece en el Panel de control, o por qué una desinstalación manual no funciona de forma estándar.

Obtener GUID y detectar software sin MSI

En la práctica real, uno de los retos recurrentes es localizar el GUID de un producto instalado para poder desinstalarlo mediante msiexec o herramientas de despliegue. Cuando se trata de paquetes MSI, Win32_Product facilita mucho el trabajo, ya que la propiedad IdentifyingNumber devuelve precisamente ese GUID en formato estándar.

Por ejemplo, si se utiliza un comando como Get-WmiObject Win32_Product | Format-Table IdentifyingNumber, Name, LocalPackage -AutoSize, se obtiene una tabla con el nombre del producto, su GUID y la ubicación del archivo MSI en el caché de instalación de Windows. Este tipo de salida es muy útil para verificar que un agente corporativo (como soluciones de detección de fraude o herramientas de seguridad) está correctamente instalado y se puede gestionar vía MSI.

El problema aparece cuando un programa no aparece como producto MSI clásico. En algunos casos, herramientas que se distribuyen como EXE o que usan proveedores distintos pueden figurar con un ProviderName diferente, por ejemplo “Programs” en lugar de “msi”. En esas situaciones, intentar obtener el GUID usando solo Win32_Product no funciona, porque sencillamente no existe un identificador MSI que se pueda pasar a msiexec.

Un caso típico en entornos corporativos es el de un técnico que recibe varios portátiles (por ejemplo, una remesa de HP ProBook) llenos de software preinstalado por el fabricante. Parte de su trabajo consiste en eliminar todo el bloatware. Para muchos programas prebinstalados, basta con consultar Win32_Product o las claves de Uninstall y obtener el GUID o la cadena de desinstalación. Pero siempre acaba habiendo un par de aplicaciones que no siguen el patrón estándar.

Cuando el ProviderName es “Programs” u otro valor no asociado a MSI, suele ser necesario buscar la cadena de desinstalación directamente en el registro. Allí, en UninstallString, se puede encontrar el comando que el sistema utiliza para eliminar la aplicación, aunque no se disponga de un GUID típico de Windows Installer. A partir de esa cadena, se pueden construir scripts que llamen a ese ejecutable con los parámetros adecuados para desinstalar en silencio.

En casos más complejos, si el proveedor no expone un MSI claro ni una UninstallString estándar, puede tocar recurrir a herramientas adicionales o a documentación específica del fabricante. No obstante, en muchos entornos se intenta resolver la mayoría de estos escenarios sin instalar software extra, apoyándose únicamente en PowerShell, WMI y el propio registro del sistema.

Verificación de agentes y herramientas específicas con Win32_Product

Además del uso generalista en inventario, hay escenarios concretos en los que las organizaciones necesitan validar a bajo nivel que un agente de software concreto está presente y correctamente instalado. Un ejemplo típico son los agentes encargados de monitorización, seguridad o análisis de fraude, que deben estar desplegados de forma homogénea en toda la flota de equipos.

En estos casos, un comando como get-wmiobject Win32_Product | Format-Table IdentifyingNumber, Name, LocalPackage -AutoSize resulta muy práctico. La salida proporciona el nombre del producto, el ID de producto (GUID) y la ubicación del archivo MSI almacenado en el caché de instalación de Windows. Con esta información se puede verificar que el paquete adecuado está instalado y que su MSI se encuentra disponible para posibles reparaciones o desinstalaciones controladas.

Determinadas soluciones comerciales, como plataformas de detección de fraude avanzadas, documentan explícitamente el uso de Win32_Product como método soportado para comprobar su agente. En estos manuales se recalca que la información devuelta es confidencial y está destinada exclusivamente a clientes autorizados, prohibiendo su publicación en fuentes abiertas o de acceso público, lo cual subraya la sensibilidad de algunos entornos corporativos.

Otro uso frecuente de Win32_Product es identificar rápidamente la versión de una suite ofimática como Microsoft Office, instalada mediante MSI tradicional. Basta con filtrar por el nombre del producto y consultar la propiedad Version para comprobar qué release concreta hay en un equipo, algo muy útil cuando se gestionan migraciones o actualizaciones masivas y se necesita saber a qué punto de partida se enfrenta cada máquina.

Este tipo de verificaciones combinan muy bien con sistemas de inventario centralizado y herramientas de gestión remota. Aunque Win32_Product no sea ideal para un escaneo masivo en cientos de equipos de golpe, sí es muy cómodo como comprobación puntual o como parte de scripts de validación posteriores a un despliegue.

Dominar las diferentes fuentes de información sobre software instalado en Windows (WMI, registro, Panel de control y líneas de comando) permite afrontar tareas como inventario, desinstalación masiva, verificación de agentes y control de versiones con mucha más soltura y menos improvisación, lo que termina ahorrando tiempo y dolores de cabeza en el día a día de la administración de sistemas.

Artículo relacionado:

Cómo obtener una lista de todo el software instalado desde PowerShell

Isaac

Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.