Cómo gestionar actualizaciones con MSIX en Windows

Si trabajas con despliegues en Windows, tarde o temprano te enfrentas al mismo problema: cómo actualizar aplicaciones sin liarla con el usuario ni destrozar el ancho de banda de la red. Con la llegada del formato MSIX y de todo el ecosistema que Microsoft ha montado alrededor, gestionar actualizaciones ya no va solo de “bajar un instalador nuevo y ejecutarlo”, sino de orquestar bien cuándo, cómo y desde dónde se actualiza.

En este artículo vamos a ver, con calma pero sin rodeos, cómo gestionar actualizaciones con MSIX dentro y fuera de Microsoft Store, qué papel juegan los archivos AppInstaller, PowerShell, los CSP de MDM y la nueva plataforma de orquestación de Windows Update, y por qué MSIX está llamado a sustituir a MSI y AppX en muchos escenarios empresariales.

Qué aporta MSIX en la gestión de actualizaciones

MSIX nace como evolución moderna de los formatos MSI, EXE y AppX, combinando lo mejor de cada casa: la facilidad de despliegue de MSI, la contenedorización y limpieza de AppX y la flexibilidad que pedían las aplicaciones Win32 clásicas (Win32, WPF, WinForms, .NET Framework, etc.).

Al empaquetar tus apps en MSIX, la instalación y desinstalación se realizan dentro de un contenedor controlado, de forma que todos los archivos y claves de registro siguen reglas estrictas y predecibles. Cuando quitas la app, se va todo detrás y evitas la típica “podredumbre de Windows” que dejan décadas de MSI y EXE instalados y desinstalados.

Otra ventaja clave para las actualizaciones es que MSIX está construido desde el inicio para soportar actualizaciones diferenciales: solo se descargan los bloques modificados del paquete, no el paquete entero. Esto marca la diferencia en redes corporativas grandes o con enlaces limitados.

Además, MSIX no se limita a Microsoft Store: puedes distribuir paquetes por tu cuenta, vía web, recursos compartidos o herramientas de gestión como Configuration Manager, Intune, Citrix o VMware, manteniendo igualmente las ventajas de contenedor y actualización eficiente.

Cómo funciona la actualización diferencial en MSIX

Para entender por qué MSIX optimiza tan bien las actualizaciones, hay que fijarse en un componente concreto: el archivo AppxBlockMap.xml, que actúa como mapa de bloques para todos los archivos del paquete.

Durante el empaquetado se genera un fragmento de metadatos que se incrusta en el propio archivo .msix o .msixbundle. Este bloque de metadatos permite a Windows identificar de manera única cada parte del paquete, de forma que puede comparar una versión antigua y una nueva y decidir exactamente qué trozos hay que descargar.

El fichero AppxBlockMap.xml es un documento XML con una matriz de información por archivo: primero se detallan datos generales (nombre, tamaño, etc.) y luego se enumeran los hashes SHA2-256 de cada bloque de 64 KB del archivo. Cada bloque se representa con un hash independiente, de modo que si solo cambia una parte de un archivo, únicamente se actualizan esos bloques.

En la práctica, cuando publicas una nueva versión de tu MSIX, Windows compara los hashes de bloques entre la versión instalada y la nueva. Si algún bloque ha cambiado, se descarga; si no, se reutiliza el bloque ya presente en el dispositivo. Si un archivo completo es idéntico (todos sus bloques coinciden), se reaprovecha tal cual y no se baja de nuevo.

Este enfoque hace que las actualizaciones funcionen de cualquier versión a cualquier otra (siempre que el paquete de destino tenga versión superior o se fuerce el cambio de versión), minimizando ancho de banda y tiempo de instalación, especialmente cuando los paquetes residen en recursos compartidos o repositorios externos.

Restricciones importantes al actualizar paquetes MSIX

Aunque el motor de actualización de MSIX es muy flexible, hay una serie de reglas que conviene tener claras antes de montar tu estrategia de versiones y despliegues, sobre todo en entornos empresariales donde no apetece romper nada en producción.

En primer lugar, las actualizaciones siempre se producen dentro de la misma familia de paquete. El Package Family Name combina el nombre del paquete y el publicador (por ejemplo, Contoso.ContosoApp_8wekyb3d8bbwe). Si cambias estos datos, estarías hablando de otra familia distinta, y ya no es una actualización sino una instalación paralela.

Por defecto, la actualización exige que la nueva versión tenga un número superior a la instalada. El proceso estándar bloquea intentos de downgrade. Sin embargo, desde Windows 10 versión 1809, puedes usar opciones como ForceUpdateFromAnyVersion (en PowerShell, CSP, API PackageManager o en el propio AppInstaller) para permitir actualizar tanto hacia arriba como hacia abajo si necesitas retroceder a una build anterior.

Otro detalle relevante es que la arquitectura puede cambiar en la actualización, mientras la nueva arquitectura sea compatible con el sistema. Un ejemplo típico: tienes una app MSIX x86 en un Windows 10 x64 y más tarde despliegas una versión x64; el sistema actualizará sin problema de x86 a x64.

Por último, debes tener en cuenta el tipo de paquete: se puede pasar de un MSIX simple a un MSIXBundle, pero no al revés. Si un dispositivo tiene instalado un bundle, las siguientes actualizaciones deberán seguir siendo bundles, para mantener la coherencia del modelo de recursos.

Optimizar la tecnología de actualización diferencial

Para sacarle todo el jugo a la actualización diferencial de MSIX, no basta con empaquetar y listo: conviene diseñar la estructura interna del paquete pensando en cómo se van a modificar los archivos a lo largo del tiempo.

Una primera recomendación es mantener los archivos relativamente pequeños. Si creas un único archivo gigante que cambias a menudo, un cambio significativo puede obligar a descargar buena parte del archivo. En cambio, dividir en varios ficheros más contenidos suele reducir el tamaño de las descargas.

También ayuda que los cambios sean lo más aditivos posible. Si las modificaciones se concentran en añadir datos o bloques nuevos, en lugar de reescribir por completo los existentes, el sistema solo tendrá que descargar esos bloques modificados, manteniendo el resto tal cual.

En la medida de lo posible, intenta que los cambios se concentren dentro de bloques de 64 KB. Si tu app trabaja con archivos muy grandes y necesitas modificar zonas internas, es preferible agrupar la lógica para que las modificaciones no vayan salpicando muchos bloques distintos, y así el impacto en el tamaño de actualización se mantiene controlado.

Actualizaciones automáticas y reparación con archivos AppInstaller

Cuando distribuyes apps MSIX fuera de Microsoft Store, entra en juego un componente clave: el archivo App Installer (.appinstaller). Este fichero define la configuración de actualización automática y reparación para cada aplicación, y permite que Windows gestione dichas operaciones sin que tú tengas que reinventar la rueda.

Al instalar una app mediante su archivo AppInstaller, Windows crea una entrada en el repositorio del Instalador de aplicaciones con las opciones que hayas configurado. Esa entrada puede modificarse después desde la app Configuración de Windows, vía PowerShell o a través de CSP si gestionas los equipos con MDM, pero cualquier cambio se aplica a esa aplicación concreta y sobrescribe la configuración previa.

En la práctica, AppInstaller te deja decidir si la app comprueba actualizaciones al iniciar, si se revisan en segundo plano, si se avisa al usuario o se hace todo en silencio, e incluso si es obligatorio actualizar antes de poder abrir la aplicación, bloqueando la activación hasta tener la última versión.

Las apps usan por defecto la ruta URI principal definida en el AppInstaller para buscar actualizaciones. Si ese origen no está disponible, pueden recurrir a uno o varios UpdateURI de reserva. El sistema intentará cada URI hasta encontrar un AppInstaller accesible y válido, que será el que determine si hay una nueva versión.

La sección de actualización dentro del AppInstaller admite elementos como HoursBetweenUpdateChecks (frecuencia mínima entre comprobaciones), ShowPrompt (mostrar o no una UI cuando se comprueba o instala una actualización) y UpdateBlocksActivation (decidir si la app puede abrirse sin actualizar o si se fuerza la actualización antes de iniciar).

Configuración avanzada con UpdateSettings en AppInstaller

El comportamiento fino de las actualizaciones se define con el elemento UpdateSettings del archivo AppInstaller. Aquí decides no solo cuándo se buscan actualizaciones, sino también cómo se aplican y qué margen tiene el usuario.

Por un lado, puedes elegir si las comprobaciones se hacen únicamente al iniciar la aplicación (OnLaunch) o si también se realizan en segundo plano mediante AutomaticBackgroundTask, cada cierto número de horas y sin intervención directa del usuario.

Cuando utilizas OnLaunch, entran en juego varios atributos: HoursBetweenUpdateChecks marca el intervalo mínimo en horas entre comprobaciones; ShowPrompt determina si se muestra una ventana informando de la actualización; y UpdateBlocksActivation define si la app puede iniciarse sin actualizar o si se obliga al usuario a aplicar el parche antes de abrirla.

Si UpdateBlocksActivation está en true, el usuario solo puede elegir entre actualizar o cerrar la app. Si está en false, se le ofrece actualizar ahora o continuar sin actualizar, dejando que el sistema aplique el cambio en segundo plano más adelante. Estas opciones están disponibles a partir de ciertas versiones de Windows 10 (1903 o superior, según el atributo).

AutomaticBackgroundTask, por su parte, realiza comprobaciones regulares cada 8 horas aproximadamente, independientemente de que el usuario abra o no la app. Este mecanismo no puede mostrar interfaz, por lo que es ideal para mantener todo al día con mínimo ruido para el usuario.

Finalmente, el atributo ForceUpdateFromAnyVersion te permite romper la regla clásica de “solo hacia adelante” y actualizar tanto a versiones superiores como inferiores, algo muy útil si tienes que corregir una regresión volviendo temporalmente a una build previa.

Actualización y reparación automática vía CSP y MDM

En entornos empresariales, lo habitual es que los dispositivos se gestionen con soluciones de movilidad como Microsoft Intune o herramientas MDM de terceros. Para esos casos, Microsoft amplió el Enterprise Modern App Management CSP, que permite controlar la actualización y reparación automática de apps MSIX no procedentes de Store.

La configuración de actualización automática se encuentra en una ruta CSP tipo ./Device/Vendor/MSFT/EnterpriseModernAppManagement/AppManagement/nonStore/<Windows app Family Name>/AppUpdateSettings/AutoUpdateSettings/AutoUpdateSettings/, donde cada nodo maneja aspectos concretos del comportamiento.

Entre los parámetros disponibles están PackageSource (origen del archivo .appinstaller que se usará para buscar actualizaciones), AutomaticBackgroundTask (si se comprueba y actualiza en segundo plano), OnLaunchUpdateCheck (comprobación al inicio), HoursBetweenUpdateChecks, ShowPrompt (mostrar diálogos de actualización o reparación) y UpdateBlocksActivation (si la app puede iniciarse cuando hay una actualización pendiente).

Otros ajustes interesantes son ForceUpdateFromAnyVersion, que habilita actualizaciones ascendentes o descendentes, y el valor Disable, que indica si la actualización automática está activa o desactivada para un paquete concreto. Con estos parámetros, los administradores pueden afinar al máximo la experiencia de actualización en flotas grandes.

Para la reparación automática, el CSP utiliza una ruta equivalente terminada en …/AutoRepair/, con un ajuste principal: PackageSource, que apunta al origen del archivo .appinstaller o del propio paquete MSIX que se usará para reparar la app si detecta problemas.

En ambos casos, la combinación de CSP y MDM permite aplicar políticas centralizadas de actualización y reparación sin que el usuario tenga que hacer nada, manteniendo las apps internas y de terceros alineadas con la estrategia de seguridad y soporte de la empresa.

Gestión de actualizaciones con PowerShell

Para administradores y scripts automatizados, PowerShell sigue siendo una herramienta fundamental a la hora de auditar y configurar la actualización de apps MSIX instaladas mediante AppInstaller.

En particular, existen cmdlets como Get-AppxPackageAutoUpdateSettings, que devuelven la configuración actual de actualización y reparación para una app concreta o para todas las que tengan entrada en el repositorio de Instalador de aplicaciones, permitiendo ver rápidamente cómo está configurado el entorno.

Del lado de la configuración, Set-AppxPackageAutoUpdateSettings permite ajustar opciones de actualización automática y reparación para un paquete instalado desde un archivo AppInstaller, sobreescribiendo la configuración existente cuando sea necesario.

Además, el despliegue y actualización directa de paquetes MSIX se realiza habitualmente con el cmdlet Add-AppxPackage, que incorpora parámetros específicos para controlar la experiencia de usuario durante una actualización.

Entre esos parámetros destacan -DeferRegistrationWhenPackagesAreInUse (evita actualizar mientras la app está en uso), -ForceApplicationShutdown (cierra los procesos activos del paquete y sus dependencias para aplicar la actualización), -ForceUpdateFromAnyVersion (permite registrar una versión concreta independientemente de que exista otra superior registrada) y -Update (marca el paquete como actualización de una dependencia existente).

También existen opciones como -InstallAllResources (fuerza la instalación de todos los paquetes de recursos incluidos en un lote) o -RetainFilesOnFailure (conserva los archivos creados en caso de fallo de implementación), útiles en escenarios de prueba y diagnóstico de despliegues MSIX complejos.

Actualizaciones iniciadas desde el propio código de la aplicación

Uno de los puntos fuertes de MSIX es que, si envías tu app en este formato, puedes iniciar actualizaciones de forma programática desde la propia aplicación, sin depender exclusivamente de la lógica de AppInstaller o de MDM.

Para ello, necesitas declarar en el manifiesto la capacidad packageManagement dentro de la sección Capabilities. Esta capacidad habilita el uso de las API Windows.Management.Deployment.PackageManager, que son las que permiten descargar y aplicar paquetes nuevos desde código.

Si la app se distribuye mediante un archivo AppInstaller, las actualizaciones iniciadas por código deberían seguir usando las APIs específicas de AppInstaller, como PackageManager.AddPackageByAppInstallerFileAsync o PackageManager.RequestAddPackageByAppInstallerFileAsync, de modo que no rompas el flujo de actualización definido para esa app.

Para comprobar si hay una versión nueva disponible cuando usas AppInstaller, puedes llamar a Package.CheckUpdateAvailabilityAsync. Si el resultado indica que hay actualización (Available o Required), puedes encolar la instalación con AddPackageByAppInstallerFileAsync y, si es necesario, pasar la opción ForceApplicationShutdown para cerrar la instancia actual y aplicar el cambio.

En escenarios donde no usas AppInstaller, la propia aplicación puede consultar un servidor propio para averiguar si existe una versión superior (por ejemplo, leyendo un archivo de texto de versión o un servicio web), comparar con su versión actual y, en caso afirmativo, mostrar un cuadro de diálogo que ofrezca actualizar o posponer.

Una vez el usuario acepta, la app puede utilizar PackageManager.AddPackageAsync apuntando al paquete MSIX o al paquete opcional correspondiente, pasando de nuevo opciones como ForceApplicationShutdown para que Windows cierre la app y complete la instalación sin intervención adicional.

Reinicio automático de la aplicación tras una actualización

Algo que se suele pasar por alto es qué ocurre después de instalar la nueva versión: ¿vuelve a arrancar sola la aplicación o el usuario tiene que hacerlo a mano? La respuesta depende del tipo de app y de cómo lances la actualización.

En el caso de las aplicaciones UWP empaquetadas como MSIX, si al aplicar la actualización pasas opciones como AddPackageByAppInstallerOptions.ForceApplicationShutdown o AddPackageOptions.ForceTargetAppShutdown, Windows puede programar el reinicio automático de la app una vez finalice la actualización.

Para aplicaciones no UWP (por ejemplo, Win32 empaquetadas en MSIX), es recomendable llamar a la API nativa RegisterApplicationRestart antes de iniciar el proceso de cierre y actualización. Esta llamada registra la instancia actual para que Windows pueda relanzarla con los parámetros indicados cuando termine la operación.

Habitualmente se usa una pequeña clase auxiliar en C# que, mediante interoperabilidad, importa RegisterApplicationRestart desde kernel32.dll y expone un método cómodo de usar en el código de negocio. Así puedes controlar, además, en qué condiciones quieres que la app se reinicie (por ejemplo, evitando reinicios tras cuelgues o errores concretos).

Con este patrón bien aplicado, consigues que la experiencia de actualización sea mucho más fluida para el usuario: se cierra la aplicación, se instala la nueva versión y, al cabo de unos segundos, el usuario vuelve al mismo punto sin tener que preocuparse por nada.

La nueva plataforma de orquestación de Windows Update

Paralelamente a MSIX, Microsoft está dando un paso más allá con lo que llama Windows Update Orchestration Platform, una capa que pretende unificar la experiencia de actualización en Windows 11 no solo para el sistema y los drivers, sino también para aplicaciones de terceros.

Hasta ahora, cada aplicación solía tener su propio mecanismo de actualización (servicios residentes, comprobadores en segundo plano, actualizadores integrados, etc.), mientras el sistema operativo y algunos controladores dependían de Windows Update. El resultado: un ecosistema fragmentado, difícil de controlar en empresas y confuso para usuarios.

Con la nueva plataforma, Microsoft permite que aplicaciones empaquetadas en MSIX, APPX o incluso ciertas Win32 con instalador personalizado se integren con Windows Update y deleguen en él la planificación y ejecución de sus actualizaciones, sin renunciar a su lógica interna.

Los desarrolladores pueden registrar sus políticas de actualización mediante APIs WinRT y comandos de PowerShell, indicando condiciones inteligentes como actividad del usuario, nivel de batería, carga del sistema, disponibilidad de energía “limpia” o ventanas horarias de baja actividad para minimizar el impacto en la experiencia de uso.

Además, todas las acciones se registran en un sistema de diagnóstico unificado y las apps pueden mostrar notificaciones nativas de Windows Update, así como aparecer en el historial de actualizaciones del sistema, lo que facilita la trazabilidad y el soporte técnico tanto en casa como en empresas.

MSI frente a MSIX: impacto real en despliegue y actualización

Durante décadas, el formato MSI ha sido el estándar de facto para la implementación de software en Windows. Ofrece instalación estandarizada, personalización mediante transformaciones (.mst), reversión, autorreparación, instalaciones administrativas por red e integración con Directiva de grupo.

El gran problema de MSI es que, con el tiempo, tiende a dejar restos en el sistema: archivos en AppData, entradas de registro, carpetas huérfanas… Todo eso contribuye a la “podredumbre de Windows” y acaba afectando al rendimiento y estabilidad del equipo.

MSIX llega precisamente para solventar este escenario, manteniendo las ventajas de administración centralizada pero añadiendo contenedorización, limpieza total al desinstalar, actualizaciones diferenciales y un modelo de seguridad más robusto (todos los paquetes deben ir firmados y validados).

Desde el punto de vista de la adopción, muchas organizaciones fueron prudentes al principio porque las primeras versiones de MSIX venían con bugs y pocas herramientas maduras de conversión. Sin embargo, el ecosistema ha ido evolucionando: Microsoft ha lanzado MSIX Packaging Tool y Package Support Framework, y terceros como TMEditX facilitan la conversión y ajuste fino de paquetes, incluso hacia formatos como AppAttach.

Hoy, con aplicaciones como Microsoft Office y la nueva versión de Teams ya empaquetadas en MSIX, y con el final de vida de App-V marcado para 2026, cada vez hay más argumentos para apostar por MSIX como formato principal de despliegue y actualización en entornos Windows modernos.

Con todo este conjunto de piezas (MSIX, AppInstaller, CSP, PowerShell y la plataforma de orquestación de Windows Update), gestionar actualizaciones con MSIX te permite pasar de parches manuales y scripts frágiles a un modelo mucho más predecible, eficiente y controlado, donde las apps se actualizan de forma diferencial, con políticas claras y sin dejar residuos, y en el que tanto usuarios como administradores tienen una experiencia mucho más limpia y coherente.