Cómo crear instaladores y paquetes MSI para Windows paso a paso

Crear instaladores MSI propios en Windows no es algo exclusivo de grandes fabricantes de software: cualquier administrador o usuario avanzado puede empaquetar aplicaciones, automatizar despliegues y añadir opciones avanzadas como instalación silenciosa, integración con consola de administración o despliegue por GPO. La clave está en entender bien qué hace un paquete MSI, qué herramientas usar y cómo estructurar el proceso para no dejar nada al azar.

Si alguna vez has pensado “tengo el programa en ZIP o EXE, pero necesito un MSI para desplegarlo por todo el dominio sin levantarme de la silla”, esta guía es para ti. Vamos a ver, con bastante detalle y en un lenguaje cercano, cómo generar paquetes MSI desde cero, cómo reempaquetar aplicaciones ya existentes, cómo integrarlos con Configuration Manager y cómo jugar con parámetros como la instalación silenciosa o el autoarranque, todo apoyado en ejemplos reales.

Qué es un paquete MSI y por qué merece la pena usarlo

Un archivo con extensión .msi es un paquete de Windows Installer, es decir, un contenedor estándar que describe qué archivos, claves de registro, accesos directos y acciones se deben aplicar en un sistema Windows para instalar, modificar o desinstalar una aplicación. Este formato lo procesa el motor de Windows Installer (msiexec.exe), que aporta toda la lógica de instalación.

Entre sus ventajas destacadas, un MSI permite despliegues desatendidos y centralizados, integración con Active Directory a través de directivas de grupo (GPO), instalación silenciosa sin intervención del usuario, reparaciones automáticas y desinstalaciones limpias. Esto evita el típico paseo de administrador con el CD o el pendrive de un PC a otro para instalar manualmente el software.

Cuando un programa viene sin MSI (por ejemplo, solo en formato ZIP o EXE clásico), se puede recurrir a herramientas de reempaquetado que observan qué cambia en el sistema al instalarlo y construyen a partir de ahí un paquete MSI propio; también existen alternativas modernas (consulta la guía completa de MSIX) que complementan estas técnicas. Es lo que vamos a ver con utilidades como WinINSTALL LE o mediante soluciones más avanzadas.

También existe un escenario más especializado: crear MSI que extiendan consolas de administración como la de Configuration Manager. En estos casos, el instalador no solo copia archivos, sino que registra extensiones, ensamblados de .NET y tipos de implementación personalizados mediante código específico y llamadas a APIs.

Creación de un MSI para extensiones de Configuration Manager

En entornos con System Center Configuration Manager (ConfigMgr), a veces se necesita registrar nuevos tipos de implementación y extender el asistente de creación de aplicaciones o la consola de administración. Para ello, se parte de un archivo de descripción de tipo de implementación (.cmdtx) y se crea un MSI que incluya tanto ese archivo como los componentes de experiencia de usuario.

El objetivo es que el archivo MSI copie los binarios y XML de extensión a las carpetas adecuadas de la consola (normalmente bajo sms\AdminConsole) y que, además, ejecute el código que llama al método DeploymentTypeExtender.Extend para registrar la nueva tecnología con el servidor de sitio o inicializar la caché local de un equipo con consola de administrador.

De forma resumida, el MSI debe contener al menos estos elementos clave de experiencia de usuario, cada uno ubicado en su ruta concreta dentro de la consola de Configuration Manager:

• Ensamblado de experiencia de usuario: un DLL .NET con nombre del estilo AdminUI.DeploymentType.<SufijoEnsamblado>.dll, que implementa la lógica de la interfaz. Debe copiarse en sms\AdminConsole\bin.
• Archivo <CreateApp_TechnologyID>.xml: define la extensión del asistente para crear aplicaciones. Se coloca en sms\AdminConsole\XmlStorage\Extensions\Forms.
• Archivo <CreateDeploymentWizard_TechnologyID>.xml: extiende el asistente de creación de tipos de implementación. También se copia en sms\AdminConsole\XmlStorage\Extensions\Forms.
• Archivo <TechnologyID>DeploymentTypePropertySheet.xml: proporciona la página de propiedades del tipo de implementación. Va en sms\AdminConsole\XmlStorage\Forms.

Durante la ejecución, el instalador debe invocar el método DeploymentTypeExtender.Extend del espacio de nombres Microsoft.ConfigurationManagement.ApplicationManagement. Esta llamada es la que realmente registra la extensión en el servidor de sitio o inicializa la caché de la consola en un equipo administrador.

El flujo típico desde código sería el siguiente: primero se crea una conexión WMI hacia el servidor de sitio con WqlConnectionManager, y luego se pasa esa conexión, junto con la ruta al archivo .cmdtx, al método Extend. Un ejemplo simplificado en C# sería:

<code>using DCM = Microsoft.ConfigurationManagement.AdminConsole.DesiredConfigurationManagement;
using Microsoft.ConfigurationManagement.ApplicationManagement;
using Microsoft.ConfigurationManagement.ManagementProvider;
using Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine;

ConnectionManagerBase connectionManager = new WqlConnectionManager();
connectionManager.Connect("SiteServerName");

DeploymentTypeExtender.Extend(
    @"C:\RdpTechnology.cmdtx", 
    new DCM.ConsoleDcmConnection(connectionManager, null),
    @"\\SiteServerName\root\sms\site_ABC");
</code>

Este código puede integrarse dentro de una acción personalizada del MSI, de forma que el propio instalador, al finalizar, se conecte al servidor de sitio, registre el nuevo tipo de implementación y deje todo listo para que la consola muestre la nueva tecnología en los asistentes.

Para poder compilar y ejecutar este tipo de extensiones necesitas referenciar varios espacios de nombres y ensamblados de Configuration Manager, entre ellos:

• Microsoft.ConfigurationManagement.ApplicationManagement
• Microsoft.ConfigurationManagement.ManagementProvider
• Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine

Y los correspondientes ensamblados:

• AdminUI.DcmObjectWrapper.dll
• AdminUI.WqlQueryEngine.dll
• DcmObjectModel.dll
• Microsoft.ConfigurationManagement.ApplicationManagement.dll
• Microsoft.ConfigurationManagement.ApplicationManagement.Extender.dll
• Microsoft.ConfigurationManagement.ManagementProvider.dll

Instalación de componentes de cliente (HandlerApplication y synclets)

Además de las extensiones de consola, muchas soluciones de Configuration Manager requieren componentes en el cliente para manejar cierto tipo de aplicaciones o configuraciones. Estos componentes suelen desplegarse como controladores (handlers) y synclets, y se integran en el agente de Configuration Manager.

El proceso típico para instalar estos componentes consiste en compilar un archivo MOF que define las clases WMI correspondientes y registrar un DLL que actuará como controlador. El paquete MSI puede automatizar estos pasos llamando a las herramientas de línea de comandos adecuadas o ejecutando scripts asociados.

En un cliente, lo normal es compilar el archivo MOF del synclet personalizado para crear la instancia necesaria de la clase CCM_AppHandler y las instancias relacionadas de CCM_HandlerSynclet. El comando suele ser algo como:

<code>C:\> mofcomp appsynclet_<technologyid>.mof</code>

A continuación, se debe copiar el DLL del controlador al directorio del cliente de Configuration Manager y registrarlo en el sistema mediante regsvr32 para que el agente lo reconozca como manejador válido:

<code>C:\> regsvr32 <technologyid>handler.dll</code>

Todo esto se puede integrar en el flujo de instalación de un MSI: el paquete puede incluir el archivo MOF, el DLL del controlador y acciones personalizadas para ejecutar mofcomp y regsvr32. De esta forma, el administrador solo tiene que desplegar el MSI de forma centralizada y no preocuparse por lanzar comandos manualmente en cada equipo.

Reempaquetar software sin MSI: ejemplo práctico con WinINSTALL LE

En muchos entornos reales, el problema más frecuente no es extender Configuration Manager, sino algo más terrenal: tienes una aplicación sin MSI (un EXE clásico o incluso solo una carpeta ZIP) y necesitas convertirla en un paquete MSI para poder desplegarla por GPO o mediante herramientas de distribución.

Para este escenario existen numerosas aplicaciones comerciales de reempaquetado, pero una opción clásica y gratuita ha sido WinINSTALL LE, que se utilizaba (y se sigue utilizando en muchos sitios) para generar MSI a partir de instalaciones existentes de forma bastante sencilla.

El enfoque de WinINSTALL LE se basa en el concepto de “fotos” del sistema: captura un estado inicial y un estado final de la máquina cliente, y a partir de las diferencias genera el paquete MSI. El proceso se puede resumir en estas fases:

• Definir el nombre y la ubicación de red donde se guardará el MSI.
• Tomar una instantánea inicial del sistema antes de instalar la aplicación.
• Instalar la aplicación de forma manual en el cliente.
• Tomar la instantánea final tras finalizar la instalación.
• Construir el MSI con todos los cambios detectados (archivos, registro, etc.).

En la práctica, se suele colocar WinINSTALL LE en un servidor, instalar y compartir la carpeta WinINSTALL (por ejemplo, en C:\Archivos de programa\OnDemand\WinINSTALL) y asignarle permisos de acceso remoto al grupo de Administradores con permiso de lectura, de forma que los clientes puedan ejecutar Discover.exe por la red.

Supongamos que quieres generar un MSI para una herramienta de compresión como FilZip 3.06. Primero creas en el servidor una carpeta de destino, por ejemplo E:\SoftAdm\FilZip306, donde se almacenará el paquete Fz306.msi y los archivos auxiliares. Luego descargas el instalador original (fz306.exe, en este caso) y lo copias al Escritorio de la máquina cliente que vas a usar para la captura.

Es muy importante que el equipo donde vayas a generar el paquete MSI no tenga ya instalada la aplicación de partida. Si la aplicación estuviera presente antes de la foto inicial, las diferencias entre la foto inicial y la final no reflejarían los cambios reales y el MSI resultante quedaría incompleto o mal definido.

Generar el MSI paso a paso con WinINSTALL LE

En el cliente, iniciando sesión con una cuenta con permisos suficientes (por ejemplo, el Administrador del dominio), ejecutas el asistente de captura de WinINSTALL LE de forma remota con un comando del estilo:

<code>\\SERVIDOR\WinINSTALL\Bin\Discover.exe</code>

En el asistente, se especifica el nombre del paquete MSI (por ejemplo, “FilZip 3.06”) y la ruta UNC donde se guardará, algo como:

<code>\\SERVIDOR\SoftAdm\FilZip306\Fz306.msi</code>

Después, el asistente te pide la unidad donde almacenará los ficheros temporales para construir la foto inicial (normalmente la C: del cliente) y te solicita seleccionar las unidades que se analizarán. Lo habitual es que, si vas a instalar la aplicación en C:, solo incluyas la unidad C: en el análisis para acotar la detección de cambios.

WinINSTALL LE ofrece varias páginas para configurar exclusiones de archivos y de registro que no quieres que formen parte del análisis (por ejemplo, ficheros temporales del sistema, logs genéricos, etc.). En la mayoría de casos se recomienda dejar las exclusiones por defecto, ya que están pensadas para evitar ruido y generalmente no impiden que el MSI se genere correctamente.

Al pulsar Finish, el asistente inicia el proceso de generación de la foto inicial. A partir de ese momento, es crítico que no se realicen cambios ajenos a la instalación de la aplicación que se quiere empaquetar. Si en medio del proceso instalas otra cosa, cambias configuraciones del sistema o actualizas drivers, esos cambios podrían acabar incluidos en el MSI y provocar comportamientos no deseados.

Cuando la foto inicial termina, el asistente te pide que selecciones el ejecutable que lanza la instalación de la aplicación objetivo (por ejemplo, fz306.exe en el Escritorio del cliente). Al hacerlo, se inicia la instalación normal de FilZip, el usuario completa todo el asistente de instalación con las opciones deseadas y, una vez acabado, se vuelve a ejecutar Discover.exe para iniciar la foto final.

En la nueva ejecución, WinINSTALL LE pregunta si quieres crear una foto inicial o realizar la foto «After». Debes seleccionar Perform the ‘After’ snapshot now, que es la opción que ordena analizar el sistema para detectar los cambios respecto a la foto inicial.

Tras pulsar Next, comienza la captura del estado final del sistema, proceso que puede llevar varios minutos. El asistente puede mostrar avisos (Warnings) sobre determinados elementos, pero en la mayoría de ocasiones no afectan a la validez del MSI generado. Al finalizar, te notificará que la foto final se ha completado y podrás cerrar el proceso.

En este punto conviene eliminar el instalador original (fz306.exe) del Escritorio del cliente y desinstalar la aplicación instalada manualmente (FilZip) desde Agregar o quitar programas (o Programas y características). El objetivo es que ese equipo quede limpio, y que cuando se instale FilZip en él, lo haga ya a través del paquete MSI que acabas de generar y no mediante el EXE manual.

Si vas al servidor y exploras la carpeta E:\SoftAdm\FilZip306, deberías ver allí el paquete Fz306.msi y otros archivos auxiliares generados por WinINSTALL LE. Con eso ya tienes un MSI listo para su despliegue por directiva de grupo u otra herramienta de distribución.

Usar políticas de grupo (GPO) para desplegar el MSI

Una vez que el paquete MSI está listo y ubicado en un recurso compartido accesible, puedes crear una GPO de instalación de software para distribuirlo de forma automática a las estaciones de trabajo del dominio. Esto es especialmente útil para aplicaciones que deben estar presentes en muchos equipos, como herramientas de compresión, visores PDF o clientes de videoconferencia.

Por ejemplo, podrías crear una nueva directiva de grupo llamada “FilZip” en tu dominio y, al editarla, ir a Configuración del equipo → Directivas → Configuración de software → Instalación de software y añadir un nuevo paquete señalando al MSI a través de la ruta de red (por ejemplo, \\SERVIDOR\SoftAdm\FilZip306\Fz306.msi).

Al seleccionar la opción de asignar el paquete a los equipos, cada vez que un ordenador del dominio arranque y reciba esa GPO, instalará la aplicación de forma automática antes de que el usuario inicie sesión, siempre que tenga acceso al recurso compartido donde se aloja el MSI.

Este mismo enfoque se puede aplicar a muchas otras aplicaciones para las que hayas generado MSI con WinINSTALL LE u otra herramienta similar. Lo más importante es asegurarse de que el recurso compartido que contiene los MSI tenga permisos de lectura para los equipos y usuarios objetivo, y que la ruta se especifique siempre como UNC y no como unidad local.

Algo similar se recomienda con soluciones de seguridad, como Trend Micro, que aconsejan utilizar la sección de Configuración de equipo en lugar de Configuración de usuario en las GPO para garantizar que la instalación del paquete MSI se produzca correctamente, independientemente de quién inicie sesión. De esta forma, los agentes o clientes de seguridad se despliegan siempre a nivel de máquina.

Qué hacer cuando la aplicación no tiene instalador “formal”

En ocasiones, la aplicación que quieres distribuir no viene siquiera en un EXE de instalación, sino que simplemente consiste en una carpeta con ejecutables y archivos que se copian a mano al disco duro. En este caso, también puedes usar WinINSTALL LE u otra herramienta de captura, con un ligero matiz en el proceso.

El flujo es el mismo: lanzar la aplicación de captura, definir el nombre del paquete y la ruta donde guardar el MSI, seleccionar unidades a analizar y tomar la foto inicial. La diferencia llega cuando el asistente te pida el ejecutable que lanza la instalación de la aplicación. Como no existe tal EXE, en ese punto simplemente cancelas la selección.

Después de cancelar esa ventana, copias manualmente las carpetas y archivos de la aplicación a las rutas deseadas en el disco (por ejemplo, C:\Herramientas\MiApp). Al terminar, vuelves a ejecutar Discover.exe, eliges realizar la foto final y WinINSTALL LE detectará todas las copias y cambios realizados entre la foto inicial y la final, generando igualmente un MSI que replicará esas acciones en otros equipos.

Este enfoque es muy práctico para pequeñas utilidades portables, herramientas internas o aplicaciones antiguas que no disponen de un instalador estándar, pero que quieres tener bajo control a través de MSI y GPO.

Editar paquetes MSI existentes y trabajar con transformaciones MST

Además de generar nuevos MSI, suele ser útil poder modificar propiedades o comportamientos de paquetes ya existentes. La consola de WinINSTALL LE permite abrir paquetes almacenados en una ruta determinada (por ejemplo, \\SERVIDOR\SoftAdm) y ajustar aspectos como archivos incluidos, entradas de registro o datos de licencia.

No obstante, si no se tiene experiencia, es recomendable no tocar valores internos del MSI a la ligera, ya que un cambio inapropiado puede romper la instalación desatendida o provocar fallos difíciles de depurar. Siempre es buena idea guardar una copia de seguridad del MSI original antes de editarlo.

Otra vía muy habitual en el mundo MSI es el uso de archivos MST (transformaciones) para personalizar un instalador sin modificar el paquete base. Herramientas como Orca (incluida en el SDK de Windows Installer) permiten crear una transformación que cambie propiedades (por ejemplo, desactivar autoupdate, forzar una configuración concreta o definir parámetros corporativos) y aplicar ese MST durante la instalación.

Pensemos, por ejemplo, en el cliente de Zoom, que se distribuye como MSI y permite opciones como la instalación silenciosa y el autoarranque. Un comando típico podría ser:

<code>msiexec /i ZoomInstallerFull.msi /quiet /qn /norestart /log install.log ZOOMAUTOSTART="true"</code>

Aquí msiexec es la aplicación que procesa el MSI y recibe tanto parámetros generales (como /quiet, /qn, /norestart o /log) como propiedades públicas del propio MSI (en este caso, ZOOMAUTOSTART=»true»). Estas propiedades se pueden pasar directamente en la línea de comandos o integrarlas de forma persistente en una transformación MST para que, al desplegar el MSI por GPO, esas propiedades se apliquen sin necesidad de escribir la línea de comandos completa, o bien usar herramientas modernas para automatizar instalaciones como Winget.

Cuando te planteas: “¿puedo editar el MSI para que lleve ya incorporados esos parámetros?”, lo más correcto a nivel de buenas prácticas corporativas suele ser crear un MST con Orca que ajuste las propiedades que quieras (por ejemplo, ZoomAutoStart, DisableAutoUpdate, etc.) y desplegar el MSI junto con esa transformación en lugar de modificar el MSI original.

Buenas prácticas y recomendaciones para trabajar con MSI

Aunque el proceso de crear y distribuir paquetes MSI pueda parecer complejo al principio, siguiendo algunas pautas básicas se vuelve mucho más manejable. Una de las recomendaciones más importantes es usar siempre máquinas limpias para capturar instalaciones cuando reempaquetas con herramientas de snapshot, de manera que las diferencias detectadas se correspondan realmente con la aplicación objetivo.

También conviene mantener una estructura clara en el servidor donde almacenas tus MSI (por ejemplo, E:\SoftAdm con subcarpetas por aplicación y versión) y limitar los permisos de escritura a los administradores, dejando lectura para los equipos y usuarios que solo necesitan instalar.

Si trabajas con extensiones de Configuration Manager o componentes que deban registrarse en WMI o como controladores, revisa siempre la documentación de Microsoft y de tu proveedor, respetando las rutas sms\AdminConsole correctas y asegurándote de que los ensamblados y archivos XML se copian donde deben. Cualquier desajuste de ruta puede hacer que la consola no muestre tus extensiones.

En el caso de despliegues por GPO, recuerda utilizar Configuración de equipo para aplicaciones críticas o de seguridad y verificar que el recurso compartido está accesible en el arranque del equipo. Y si necesitas pasar parámetros personalizados (como en Zoom), estudia si es mejor usar transformaciones MST en lugar de alterar el MSI base.

Al final, dominar el empaquetado MSI y las herramientas asociadas, como Chocolatey y Ninite, te permite automatizar el despliegue de software, ahorrar muchísimo tiempo en instalaciones manuales y tener un control mucho más fino sobre lo que se instala en cada puesto, desde pequeñas utilidades como FilZip hasta soluciones complejas integradas con Configuration Manager.