Gestionar actualizaciones con MSIX en Windows

Inicio » Windows » Gestionar actualizaciones con MSIX de forma eficiente y segura

MSIX ofrece un modelo de empaquetado moderno con actualizaciones diferenciales por bloques que reducen el ancho de banda y los tiempos de instalación.
El archivo App Installer, PowerShell y Enterprise Modern App Management CSP permiten controlar de forma granular cómo, cuándo y desde dónde se actualizan y reparan las aplicaciones.
MSIX app attach y la futura Windows Update Orchestration Platform integran las apps MSIX en infraestructuras VDI y en el propio ecosistema de Windows Update.

Gestionar actualizaciones con MSIX se ha convertido en uno de los puntos críticos para cualquier equipo que distribuye aplicaciones en Windows, ya sean herramientas internas de una empresa o productos comerciales. Ya no se trata solo de “empaquetar e instalar”, sino de controlar cómo se actualizan, cómo se reparan y cómo se integran con plataformas como Windows Update, Microsoft Store, Intune, Azure Virtual Desktop o Citrix.

Mientras que con instaladores clásicos como EXE o MSI cada aplicación iba “a su bola” con su propio actualizador, MSIX propone un modelo unificado, diferencial y mucho más limpio, donde el sistema operativo entiende qué versión hay instalada, qué bloques de datos han cambiado y cómo aplicar la actualización de la forma menos intrusiva posible para el usuario y para la red.

Qué es MSIX y por qué cambia la forma de actualizar aplicaciones

Tipos de paquetes MSIX y relación con la actualización

Dentro del ecosistema MSIX hay varios formatos relacionados que influyen directamente en cómo se entregan las actualizaciones y desde dónde se descargan:

Paquete de aplicación (.msix / .appx): es el paquete principal para una arquitectura concreta (x86, x64, ARM, etc.). Cuando se lanza una nueva versión, se publica un nuevo archivo MSIX con versión superior.
Paquete de aplicaciones (.msixbundle / .appxbundle): agrupa varios MSIX para distintas arquitecturas bajo un único archivo. El sistema elige la variante óptima para el dispositivo y las actualizaciones se gestionan también a nivel de bundle, lo que simplifica muchísimo la distribución.
Archivo de carga (.msixupload / .appxupload): orientado a publicar en Microsoft Store. Contiene uno o varios bundles, más símbolos para telemetría y análisis de errores, y se usa para que la Store gestione automáticamente la entrega de nuevas versiones.

Además, en escenarios de MSIX app attach se usan contenedores como .vhd, .vhdx y .cim, que almacenan el contenido expandido del paquete. Las actualizaciones, en estos entornos, pasan por actualizar la imagen que contiene la versión nueva del MSIX y gestionar su adjuntado o sustitución en los hosts de sesión o VDA.

Cómo se empaquetan y preparan las aplicaciones para MSIX

Antes de hablar de actualización hay que hablar de empaquetado. Microsoft ofrece MSIX Packaging Tool para convertir instaladores MSI, EXE, App-V 5.x o despliegues ClickOnce al nuevo formato. Está disponible en Microsoft Store y en paquetes offline, y se puede usar tanto con interfaz gráfica como desde línea de comandos.

Los requisitos básicos para trabajar con MSIX Packaging Tool incluyen Windows 10 versión 1809 o superior, permisos de administrador y (si se instala desde la Store) una cuenta Microsoft o corporativa. En entornos empresariales se suele combinar con herramientas como MSIX Manager, MSIX Hero o soluciones de terceros que automatizan la conversión a contenedores VHD/VHDX/CIM para escenarios de app attach.

Conviene hacer una preparación de la aplicación antes de empaquetar: validar que funciona correctamente en los dispositivos objetivo, optimizar rendimiento (CPU, memoria, tiempos de arranque) con las herramientas de perfilado de Visual Studio y comprobar que las builds de Release, especialmente si usan .NET Native, se comportan como se espera. MSIX mejora la instalación y actualización, pero no arregla por arte de magia una app mal diseñada.

El papel del manifiesto MSIX en las actualizaciones

El archivo Package.appxmanifest es el corazón del paquete MSIX. Define la identidad (nombre, editor, versión), los iconos, las capacidades, asociaciones de archivo, protocolos, tareas en background y otros puntos de extensión que influyen también en la experiencia de actualización.

Visual Studio ofrece un diseñador visual para el manifiesto, evitando que tengas que editar XML a mano. Desde ahí puedes ajustar los datos de publicación, el certificado de firma, los recursos visuales o configuraciones avanzadas que, a la larga, determinarán cómo se muestra la app en App Installer, en la Store o en el menú Inicio tras una actualización.

Marc Chagall: Explorando sus America Windows en la Obra Maestra del Pintor Surrealista

Las capacidades (ubicación, cámara, red, dispositivos, etc.) deben declararse con cuidado: pedir más permisos de los necesarios puede generar fricción con los usuarios y con los equipos de seguridad. Una actualización que amplíe capacidades suele detonar prompts adicionales o revisiones de conformidad en entornos gestionados.

En el manifiesto también se configuran protocolos personalizados, asociaciones de archivo y alias de ejecución. Estos vínculos se mantienen a través de las actualizaciones siempre que la identidad de paquete y la lógica declarada sigan siendo coherentes, lo que garantiza que los enlaces profundos, los dobles clics de archivos y los comandos de consola sigan funcionando al cambiar de versión.

Tecnología de actualización diferencial en MSIX

Uno de los grandes puntos fuertes de MSIX es su mecanismo de actualización diferencial, pensado para descargar únicamente los “trozos” de la aplicación que realmente cambian entre versiones. Esto tiene impacto directo en el ancho de banda consumido, el tiempo de instalación y la experiencia global en redes corporativas saturadas o conexiones remotas.

Durante la creación del paquete se genera un fragmento de metadatos que se almacena dentro del propio archivo MSIX o MSIXbundle. Ese metadato, contenido en AppxBlockMap.xml, describe todos los archivos del paquete en dos dimensiones: por un lado, información general (nombre, tamaño, etc.) y, por otro, hashes SHA2-256 de cada bloque de 64 KB de esos archivos.

Esto significa que cada fichero del paquete queda dividido en bloques de 64 KB, cada uno con su hash. Por ejemplo, un archivo de imagen de unos 100 KB podría tener dos bloques: el primero de 64 KB y el segundo con el resto del contenido. Si en la versión nueva solo cambia el segundo bloque, el hash del primero se conserva y Windows sabe que puede reutilizarlo de la versión anterior sin volver a descargarlo.

Cuando el sistema inicia una actualización, compara el AppxBlockMap.xml del paquete antiguo con el del nuevo. De esa comparación sale una lista de bloques que han cambiado y solo esos son los que se descargan desde el origen (red local, servidor web, Microsoft Store, etc.). Si un fichero completo no ha variado (todos sus hashes de bloque son idénticos), ese archivo se reutiliza tal cual.

Gracias a este enfoque, la maquinaria de actualización diferencial funciona de cualquier versión a cualquier otra versión superior del mismo paquete, sin necesidad de generar “parches intermedios”. Mientras el paquete destino tenga una numeración de versión superior al paquete origen y comparta identidad de familia, el sistema puede calcular los bloques modificados y descargar únicamente lo imprescindible.

Restricciones importantes al actualizar paquetes MSIX

El proceso de actualización con MSIX tiene una serie de reglas que hay que respetar para evitar errores o comportamientos inesperados:

Misma familia de paquetes: el nombre de familia (package family name) combina el nombre de paquete y el publicador. La actualización solo es posible si la nueva versión mantiene esa misma identidad. Por ejemplo: Contoso.ContosoApp_8wekyb3d8bbwe.
La versión debe avanzar: de forma predeterminada, solo se permiten actualizaciones a versiones superiores. El sistema bloqueará la instalación de versiones anteriores para evitar regresiones accidentales.
ForceUpdateFromAnyVersion: a partir de Windows 10 1809, se puede forzar el salto a versiones anteriores o no secuenciales usando esta opción en el archivo AppInstaller, en la API PackageManager, en determinados cmdlets de PowerShell o a través de EnterpriseModernAppManagement CSP.
Cambio de arquitectura: el paquete actualizado puede tener una arquitectura distinta siempre que sea compatible con el sistema operativo. Por ejemplo, actualizar de x86 a x64 en un Windows 10 x64 es un escenario soportado.
De MSIX a MSIXbundle sí, a la inversa no: es posible pasar de un paquete MSIX suelto a un MSIXbundle, pero no al revés. Una vez que una app se distribuye como bundle, las siguientes actualizaciones deben seguir usando este formato.

Buenas prácticas para optimizar la actualización diferencial

La forma en que organizas los archivos dentro del paquete influye en la eficiencia de las actualizaciones. Aunque el sistema ya hace un buen trabajo identificando bloques cambiados, hay varias recomendaciones que ayudan a sacar el máximo partido:

Mantén los archivos relativamente pequeños: si un archivo enorme cambia ligeramente pero se reconstruye entero, es posible que implique descargar muchos bloques. Dividir recursos grandes en ficheros más pequeños reduce el impacto de cambios localizados.
Haz cambios aditivos siempre que puedas: si los cambios se limitan a añadir contenido al final de un archivo en vez de reescribirlo entero, el número de bloques nuevos será menor y la actualización será más ligera.
Limita los cambios a bloques de 64 KB: aunque no siempre es posible, diseñar el formato de datos para que los cambios se agrupen en ventanas de 64 KB facilita que solo se modifiquen uno o pocos bloques en lugar de arrastrar cambios al resto del fichero.

Archivo App Installer (.appinstaller) y gestión de actualizaciones

El archivo App Installer (.appinstaller) es la pieza clave para controlar el comportamiento de actualización de una app MSIX cuando se distribuye fuera de Microsoft Store (lo que se conoce como sideloading). En este archivo XML se define desde qué URI se instala o actualiza la aplicación y qué políticas se aplican al buscar nuevas versiones.

La configuración de actualización se agrupa en el elemento UpdateSettings y permite ajustar, entre otros, los siguientes aspectos:

OnLaunch: indica que la app comprobará si hay actualización al iniciarse. Admite atributos como:
- HoursBetweenUpdateChecks: entero de 0 a 255 que define la frecuencia mínima (en horas) entre comprobaciones de actualización. El valor por defecto, si no se especifica, es 24.
- ShowPrompt: booleano que establece si se mostrará interfaz al usuario cuando haya una actualización disponible.
- UpdateBlocksActivation: booleano que determina si la actualización bloquea el inicio de la app. Si es true, el usuario solo puede actualizar o cerrar; si es false, puede seguir usando la app y la actualización se aplicará de forma más transparente en otro momento.
AutomaticBackgroundTask: permite que el sistema compruebe actualizaciones en segundo plano, aproximadamente cada 8 horas, independientemente de si se abre la aplicación. Esta modalidad no muestra interfaz de usuario.
ForceUpdateFromAnyVersion: habilita el salto tanto hacia versiones superiores como hacia inferiores. Sin este ajuste, solo se permiten actualizaciones ascendentes.

¿Cómo actualizar datos de una hoja de Excel a otra automáticamente?

En el propio archivo App Installer se pueden definir también UpdateURI y rutas alternativas, de modo que si la ubicación principal del .appinstaller no está accesible, la aplicación tenga otros orígenes de actualización a los que recurrir.

Actualización automática y reparación sin usar Microsoft Store

MSIX permite gestionar actualizaciones y reparaciones automáticas sin depender de Microsoft Store, algo esencial en muchas organizaciones donde las apps se distribuyen mediante canales corporativos, portales internos o soluciones MDM/EMM.

Cuando instalas una app a través de un archivo App Installer, se crea una entrada en el repositorio de App Installer de Windows con la configuración que se haya especificado (URIs, frecuencia de comprobación, comportamiento al actualizar, etc.). Mientras exista esa entrada, la app puede seguir recibiendo actualizaciones automáticas y reparaciones desde los orígenes definidos.

La aplicación Configuración de Windows ofrece una interfaz gráfica para activar o desactivar las opciones de actualización automática y reparación para las apps que usan App Installer. Sin embargo, en entornos empresariales es más habitual controlar esto mediante ficheros .appinstaller, PowerShell o CSP.

Las apps de Windows usan por defecto la ruta URI principal del archivo App Installer para buscar actualizaciones. Si esa ruta no está disponible, el sistema puede recurrir a las direcciones especificadas en UpdateURIs, intentando conectarse a cada una hasta encontrar un paquete válido que represente una versión más reciente.

Para la reparación automática, el proceso es similar: se usa la ruta URI configurada en el archivo App Installer para localizar el origen de reparación. Si no está accesible o no se ha configurado, Windows intenta utilizar las rutas indicadas en RepairURIs para obtener el paquete de reparación necesario.

Configuración de actualización y reparación mediante PowerShell

PowerShell ofrece cmdlets específicos para leer y modificar las opciones de actualización automática y reparación de aplicaciones basadas en MSIX que se hayan instalado a través de App Installer.

Cmdlet de PowerShell	Descripción
`Get-AppxPackageAutoUpdateSettings`	Devuelve la configuración de actualización y reparación actualmente definida para una app concreta o para todas las apps configuradas.
`Set-AppxPackageAutoUpdateSettings`	Establece o modifica las opciones de actualización automática y reparación de una app instalada mediante un archivo App Installer, ajustando horas entre comprobaciones, orígenes o comportamiento de la UI.

Además, el cmdlet Add-AppxPackage es clave para instalar o actualizar paquetes MSIX en scripts y pipelines. Incluye parámetros pensados para controlar la experiencia de usuario durante la actualización:

Parámetro	Descripción
`-DeferRegistrationWhenPackagesAreInUse`	Impide que el paquete se actualice mientras el usuario lo tiene abierto, aplazando el registro hasta que la app deje de estar en uso.
`-ForceApplicationShutdown`	Fuerza el cierre de todos los procesos activos asociados al paquete o a sus dependencias para poder continuar con la instalación o actualización.
`-ForceUpdateFromAnyVersion`	Permite registrar una versión concreta del paquete aunque ya exista otra versión superior o inferior instalada, ignorando la restricción habitual de solo actualizar hacia arriba.
`-InstallAllResources`	Fuerza la instalación de todos los paquetes de recursos incluidos en un lote, saltándose la lógica de aplicabilidad de recursos.
`-RetainFilesOnFailure`	Indica que los archivos creados durante una implementación fallida no se eliminen, lo que puede ayudar en tareas de diagnóstico.
`-Update`	Especifica que el paquete es una actualización de un paquete de dependencia, de manera que su ciclo de vida queda vinculado a la aplicación primaria.

Control de actualizaciones MSIX mediante CSP y MDM

En organizaciones con gestión centralizada es habitual controlar las actualizaciones de aplicaciones MSIX a través de soluciones de administración de dispositivos móviles (MDM) como Microsoft Intune o plataformas similares.

Para ello, Microsoft ha ampliado el Enterprise Modern App Management CSP con ajustes específicos orientados a la actualización automática de apps no procedentes de Store. Estos ajustes se aplican por dispositivo y permiten gobernar, de forma granular, cómo se comporta cada aplicación en cuanto a comprobación y aplicación de nuevas versiones.

La ruta general dentro del CSP para apps no Store es:

./Device/Vendor/MSFT/EnterpriseModernAppManagement/AppManagement/nonStore/<Windows app Family Name>/AppUpdateSettings/AutoUpdateSettings/AutoUpdateSettings/

Entre las configuraciones disponibles para actualización automática se incluyen:

Ruta CSP	Descripción
`./PackageSource`	Origen del archivo .appinstaller desde el que se comprueban e instalan las actualizaciones.
`./AutomaticBackgroundTask`	Habilita o deshabilita la comprobación y aplicación en segundo plano de actualizaciones sin intervención del usuario.
`./OnLaunchUpdateCheck`	Controla si la app debe buscar actualizaciones al iniciarse.
`./HoursBetweenUpdateChecks`	Define el intervalo entre comprobaciones de actualización automáticas.
`./ShowPrompt`	Indica si se muestran diálogos al usuario cuando hay actualizaciones o reparaciones disponibles.
`./UpdateBlocksActivation`	Especifica si la app puede iniciarse cuando hay una actualización pendiente o si esta bloquea la activación hasta completarse.
`./ForceUpdateFromAnyVersion`	Permite saltar de cualquier versión a otra (superior o inferior) según las políticas definidas.
`./Disable`	Habilita o deshabilita la actualización automática para un paquete concreto.

Para la reparación automática en dispositivos Windows 10, el CSP también incluye una ruta específica:

./Device/Vendor/MSFT/EnterpriseModernAppManagement/AppManagement/nonStore/<Windows app Family Name>/AppUpdateSettings/AutoUpdateSettings/AutoRepair/

Ruta CSP	Descripción
`./PackageSource`	Especifica el origen del archivo .appinstaller o del paquete MSIX que se utilizará para realizar la reparación de la aplicación.

Como cambiar la imagen predeterminada de la cuenta de usuario en windows 10

Experiencia de instalación, pruebas locales y sideloading

Desde el punto de vista del usuario, instalar un MSIX es muy sencillo: doble clic sobre el .msix o .msixbundle y se abre App Installer, mostrando nombre, editor, versión, permisos requeridos y un botón de instalación con su barra de progreso.

Cuando generas paquetes desde Visual Studio con la opción de “App Packages”, se incluye un script Add-AppDevPackage.ps1 en una carpeta con sufijo _Test. Ejecutar ese script con PowerShell instala el certificado de desarrollo y el paquete en un solo paso, ideal para pruebas internas sin pasar por la Store.

En entornos de automatización, pipelines CI/CD o despliegues masivos, PowerShell y herramientas de gestión (Intune, Configuration Manager, etc.) se encargan tanto de la instalación inicial como de las sucesivas actualizaciones, basadas en nuevas versiones del MSIX publicadas en los orígenes corporativos.

MSIX app attach y actualizaciones en entornos virtualizados

MSIX app attach es la forma moderna de entregar aplicaciones en infraestructuras como Azure Virtual Desktop o soluciones VDI de terceros. En lugar de instalar la app dentro de cada máquina, se monta dinámicamente un contenedor (VHD, VHDX o CIM) que contiene el contenido expandido del paquete MSIX.

Estos archivos se almacenan normalmente en recursos compartidos de red o en Azure Files y se montan en los hosts de sesión o VDA cuando el usuario inicia su sesión o la aplicación. Las ventajas son claras: imágenes base más pequeñas, menor tiempo de aprovisionamiento de nuevas máquinas, gestión centralizada de versiones y menor impacto de cambios de software sobre escritorios compartidos.

Para que todo esto funcione, los paquetes MSIX deben estar firmados con certificados de confianza. Los hosts que montan los contenedores deben reconocer el certificado para permitir la ejecución de las apps contenidas.

Fabricantes como Citrix han integrado MSIX y MSIX app attach en sus plataformas, añadiendo componentes de entrega de paquetes que administran el ciclo de vida de los MSIX (y, en paralelo, otros formatos como App-V o soluciones de layering). De esta forma, la misma consola central puede publicar, versionar y revocar aplicaciones empaquetadas con MSIX en grandes granjas de escritorios virtuales.

Comparativa rápida entre MSI y MSIX en clave de actualización

MSI ha sido durante más de dos décadas el estándar corporativo para la instalación de aplicaciones en Windows, con ventajas claras: estandarización, personalización mediante transformaciones (.mst), reversión y autorreparación de instalaciones, integración con directivas de grupo y soporte sólido para despliegues masivos.

Sin embargo, las aplicaciones MSI tienden a dejar residuos (archivos en AppData, entradas de registro, configuraciones varias) incluso después de la desinstalación, contribuyendo a que el sistema se degrade con el tiempo. Las actualizaciones, además, suelen requerir paquetes completos o lógicas propias del fabricante, sin una capa diferencial integrada a nivel de plataforma.

MSIX nace precisamente para abordar estos puntos débiles: contenedorización ligera, desinstalación limpia, actualizaciones diferenciales por bloques, firma obligatoria de paquetes, gestión de estado de la aplicación y compatibilidad con las apps Win32 existentes. Los administradores pueden seguir usando herramientas conocidas como Configuration Manager o Intune para distribuir estas aplicaciones, pero aprovechando las ventajas del formato.

Durante los primeros años, muchas organizaciones fueron cautas por la falta de madurez de las herramientas de conversión y ciertas limitaciones frente a App-V. Con el tiempo, el ecosistema ha crecido (MSIX Packaging Tool, Package Support Framework, utilidades como TMEditX, soporte en VDI de Citrix y VMware, etc.) y cada vez más aplicaciones corporativas se empaquetan directamente como MSIX, incluidas piezas clave como Microsoft Office o la última versión de Microsoft Teams.

Windows Update Orchestration Platform y el futuro de las actualizaciones

Microsoft está dando un paso más en la integración de actualizaciones con la nueva Windows Update Orchestration Platform, cuyo objetivo es que incluso aplicaciones de terceros puedan apoyarse en Windows Update para gestionar su ciclo de actualización.

Hoy en día, el sistema operativo y parte de los controladores se actualizan a través de Windows Update, pero la mayoría de aplicaciones usan sus propios updaters, lo que se traduce en múltiples experiencias, múltiples servicios en segundo plano y una gestión más caótica para administradores de sistemas.

La nueva plataforma permite que los desarrolladores registren sus lógicas de actualización mediante APIs WinRT y comandos de PowerShell. De esta forma, las apps podrán programar sus actualizaciones según condiciones inteligentes: actividad del usuario, nivel de batería, rendimiento del sistema, disponibilidad de energía sostenible o ventanas horarias de baja actividad.

Las acciones quedarán registradas en un sistema de diagnóstico unificado, se integrarán con las notificaciones nativas de Windows Update y aparecerán en el historial de actualizaciones del sistema. La plataforma se orienta principalmente a apps empaquetadas en MSIX o APPX, además de aplicaciones Win32 con lógica de instalación personalizada.

Para las empresas, esto supone una oportunidad de homogeneizar aún más la experiencia de actualización, reforzar la seguridad, simplificar el soporte y aprovechar mejor herramientas de gestión como Intune, sobre todo en un contexto de migración masiva de Windows 10 a Windows 11.

Entender cómo gestionar actualizaciones con MSIX implica ir más allá del simple “subir una nueva versión”: significa diseñar paquetes que aprovechen la actualización diferencial, configurar archivos App Installer con políticas claras, orquestar comportamientos con PowerShell y CSP, y, cuando toca, integrarse con plataformas como Windows Update Orchestration o MSIX app attach. Bien planteado, este modelo permite tener aplicaciones que se instalan rápido, se actualizan con muy poco ancho de banda, se reparan de forma fiable y se desinstalan sin dejar rastro, haciendo la vida mucho más sencilla tanto a usuarios finales como a equipos de desarrollo y de TI.