Solution
EtherApps Forge capture les applications directement depuis les systèmes en cours d'exécution, prend en charge la migration App-V vers MSIX et la conversion d'applications MSIX, applique les correctifs de compatibilité du Package Support Framework, gère la signature et le travail de manifeste et produit des packages prêts pour Intune et AppAttach. Les développeurs et ISV packagent leurs propres builds par le même pipeline. Conçu pour les MSP, les partenaires de migration, les équipes IT internes et les éditeurs de logiciels.
Oct 2025
fin de support Windows 10, la fenêtre de migration est en mois, pas en années
4 formats
MSIX, MSI, IntuneWin, AppAttach depuis une capture
Sans installateur
workflow capture-first quand le média original est perdu
App-V vers MSIX
La migration App-V vers MSIX consiste à auditer le parc App-V, convertir les packages adaptés, corriger les écarts d'exécution, puis signer, tester et déployer via Intune. App-V n'est plus développé et le support serveur App-V a pris fin en avril 2026, donc la plupart des parcs planifient le passage. Comparez les principales méthodes ci-dessous.
| Méthode | Idéal pour | Points de vigilance |
|---|---|---|
| Réempaquetage manuel | Petits parcs et packages ponctuels nécessitant un contrôle total | Lent à grande échelle ; chaque package répète les mêmes étapes manuelles |
| Conversion MSIX Packaging Tool | Packages App-V 5.1 aux sources saines ; outillage Microsoft gratuit | App-V 4.x n'est pas pris en charge directement ; scripts et correctifs d'exécution nécessitent encore du travail PSF |
| Conversion par lots scriptée | Grands parcs App-V 5.1 traités via des conversions de modèle en ligne de commande | Nécessite des environnements de conversion propres et une revue par package des échecs |
| Réempaquetage capture-first (EtherApps Forge) | Packages App-V 4.x, installateurs perdus et applications complexes qui résistent à la conversion directe | Les captures nécessitent une VM contrôlée et une revue humaine avant publication |
The problem
MSIX est le format de déploiement Microsoft moderne, mais le chemin d'une application Windows héritée à un MSIX signé et déployé est étroit. Les équipes rencontrent quatre bloqueurs : média d'installateur perdu depuis des années, compétences MSIX internes rares et chères, pièges de manifeste et signature qui n'apparaissent qu'au déploiement et cibles diverses qui semblent nécessiter différentes exécutions de packaging. Intune utilise MSIX ou IntuneWin, Azure Virtual Desktop utilise AppAttach et Windows 365 utilise MSIX ou IntuneWin (Windows 365 ne supporte pas actuellement AppAttach).
Les programmes de migration qui avaient trois ans ont maintenant des mois. Le travail de packaging qui était programmé sur plusieurs vagues atterrit maintenant sur une seule vague avec peu de marge.
Les packagers expérimentés sont rares et demandés. Former une équipe de zéro étend les calendriers au-delà de la falaise de fin de support Windows 10, c'est pourquoi les routes guidées par IA et workflows capture-first comptent.
Les applications héritées n'ont souvent pas d'installateur, pas de documentation et des dépendances non documentées. Tout workflow MSIX qui dépend de média d'installateur propre ne survit pas au contact avec un vrai parc hérité.
La signature, les correctifs de manifeste et les packages de modification sont des problèmes spécifiques à MSIX que les équipes ne rencontrent que tard dans le processus. Un pipeline qui les gère en ligne est matériellement plus rapide que celui qui passe à des outils de signature externes.
What changes
Une capture produit MSIX signé pour Intune, IntuneWin pour déploiement Intune via chemin hérité, MSIX AppAttach pour Azure Virtual Desktop et MSI pour cibles héritées. La livraison Windows 365 utilise une sortie MSIX ou IntuneWin.
Signature, correctifs de manifeste et packages de modification sont gérés dans le workflow avec chaînes de certificats gérées par le client ou de confiance Microsoft, donc aucune chaîne d'outils de signature séparée requise.
Les applications legacy se comportent souvent mal dans le conteneur MSIX : elles écrivent à côté de leur propre exécutable, attendent un chemin d'installation fixe ou lisent des clés de registre machine qu'elles n'atteignent plus. Forge met en place le Package Support Framework, avec redirection des fichiers et du registre et correction du répertoire de travail, pour que l'application capturée fonctionne correctement sans modifier son code source.
Les éditeurs de logiciels et les équipes de développement internes peuvent livrer leurs propres builds en MSIX signé, pas seulement des applications legacy capturées. La CLI forge_msix remplace directement makeappx.exe de Microsoft : un dossier de build devient un package signé, validé et testé au sein d'un pipeline CI existant.
Le routage guidé par IA choisit MSI, MSIX, AppAttach ou IntuneWin par application et suggère résolution de dépendances et correctifs de compatibilité, donc les équipes de packaging sans compétences MSIX profondes continuent d'avancer.
Moins de packages coincés en retravail manuel à la fin de la vague de migration, avec une capture couvrant plusieurs cibles de livraison moderne plutôt que d'exécuter des pipelines séparés par sortie.
La vue de packaging
Capturez, signez et appliquez des correctifs de manifeste dans EtherApps Forge, puis routez via un point de contrôle de revisor vers MSIX pour Windows 11 et Intune, AppAttach pour Azure Virtual Desktop, IntuneWin pour déploiement endpoint ou MSI pour cibles héritées - tout depuis la même capture.
How we deliver it
Cette route est menée par EtherApps Forge pour sorties MSIX, MSI, IntuneWin et AppAttach capture-first avec signature et routage guidé par IA gérés en ligne. Windows 365 ne supporte pas actuellement AppAttach, donc la livraison Cloud PC utilise MSIX ou IntuneWin. Intégrez EtherInsights où le programme nécessite aussi conception de cohorte Windows 365, planification de licences ou baselines de migration depuis Azure Virtual Desktop ou VDI hérité aux côtés du flux de packaging.
EtherApps Forge captures installed Windows applications from running systems, analyses the real application footprint, supports AI-guided packaging decisions, and produces deployment-ready outputs for modern environments.
EtherInsights started as the cost management platform for Microsoft 365 and Azure. It shows where spend is going, which owners need to act, and how to turn waste into savings. It now extends that operating view into full Windows 365 lifecycle support, plus tenant, user, security, device, and Intune reporting.
Where this fits
FAQ
Gardez l'évaluation ancrée dans capture sans installateur, signature, routage de format cible et comment EtherApps Forge se tient aux côtés des équipes de packaging existantes.
Le support Windows 10 se termine en octobre 2025, Intune se standardise sur les chemins de déploiement modernes et Azure Virtual Desktop AppAttach nécessite MSIX. La fenêtre de migration s'est comprimée d'années en mois pour la plupart des équipes, et MSIX est le format qui atterrit sur Intune, AVD AppAttach et livraison Cloud PC moderne aux côtés d'IntuneWin.
Oui. Capture-first signifie aucune dépendance au média d'installateur. EtherApps Forge capture l'empreinte d'application installée depuis un système en direct (fichiers, registre, AppData, services et dépendances) et produit des sorties signées MSIX, MSI, IntuneWin et AppAttach depuis une capture. C'est la raison principale pour laquelle les équipes choisissent EtherApps Forge plutôt que les chaînes d'outils de packaging traditionnelles pour les parcs hérités.
Oui. Une capture produit MSIX signé pour Intune, IntuneWin pour déploiement Intune via chemin hérité et MSIX AppAttach pour Azure Virtual Desktop. La livraison Windows 365 utilise MSIX ou IntuneWin depuis la même capture. Windows 365 ne supporte pas actuellement AppAttach, donc la livraison Cloud PC passe par le chemin MSIX ou IntuneWin.
Non. Le routage guidé par IA augmente l'équipe en comblant le manque de compétences MSIX et en suggérant le bon chemin par application, mais un revisor humain signe encore chaque package. EtherApps Forge travaille aux côtés des workflows de packaging existants plutôt que de remplacer le jugement du packager.
Les packages App-V 5.1 peuvent être convertis directement avec le MSIX Packaging Tool de Microsoft, via l'interface ou la ligne de commande pour les exécutions par lots. Les packages App-V 4.x ne sont pas pris en charge directement ; Microsoft recommande de convertir depuis l'installateur source, et lorsque l'installateur est perdu un réempaquetage capture-first à partir d'une installation active est la route pratique. EtherApps Forge couvre ce chemin capture-first avec une revue humaine avant publication.
Les bloqueurs habituels sont les scripts de lancement et de fermeture de session, les comportements d'exécution qui supposaient le client App-V, les dépendances middleware, et les packages dont le média source n'existe plus. Le Package Support Framework corrige de nombreux écarts d'exécution après la conversion, et les packages qui résistent à la conversion directe peuvent être réempaquetés en capture-first à la place. Une courte passe d'évaluation avant la migration repère ces bloqueurs tôt.
Oui. Chaque package MSIX doit être signé avec un certificat auquel le parc fait confiance avant que Windows ne l'installe, donc planifiez la gestion des certificats comme partie intégrante du workflow de migration plutôt qu'en pensée après coup. EtherApps Forge intègre la signature dans le pipeline de packaging, et la même discipline de certificat s'applique aux packages convertis avec l'outillage Microsoft.
Attribuez les packages MSIX signés via Intune comme toute application Windows moderne, en commençant par un anneau pilote sur des postes Windows 11 représentatifs avant une attribution large. Gardez le package App-V disponible jusqu'à ce que le pilote prouve que l'application convertie se comporte correctement, puis retirez l'ancien chemin de livraison à mesure que chaque vague s'achève.
Le Package Support Framework est un runtime open source de Microsoft qui corrige des comportements dont les applications dépendent mais qu'elles ne peuvent pas exécuter dans le conteneur MSIX. Les cas courants sont l'écriture de fichiers à côté de l'exécutable, un chemin d'installation fixe attendu ou la lecture d'emplacements de registre machine que le conteneur redirige. EtherApps Forge met en place ce framework dans le cadre du packaging, avec redirection des fichiers et du registre et correction du répertoire de travail, pour qu'une application legacy capturée fonctionne correctement sans modifier son code source.
Oui. La CLI forge_msix remplace directement makeappx.exe de Microsoft et appelle le même moteur de packaging Windows : un dossier de build devient un MSIX signé et validé, avec les mêmes options que celles déjà passées par un pipeline existant. Les développeurs et ISV peuvent générer un manifeste depuis l'exécutable compilé, créer et signer en une étape, valider le résultat puis le tester, le tout comme étapes d'un pipeline de release plutôt qu'une opération manuelle après le build.
Microsoft a fait passer le client et le séquenceur App-V en support étendu fixe, donc ils sont toujours livrés avec Windows mais ne reçoivent que des correctifs, et le support des composants serveur App-V a pris fin en avril 2026. Les équipes qui utilisent déjà des packages App-V sur Azure Virtual Desktop peuvent utiliser App-V app attach sans serveur App-V, et la plupart des parcs profitent de cette fenêtre pour planifier une migration App-V vers MSIX maîtrisée.
Start here
Commencez par un essai EtherApps Forge de 7 jours sur une vraie application, ou réservez une démo pour parcourir packaging MSIX capture-first, signature et routage AppAttach avant que la fin de support Windows 10 ne comprime davantage le calendrier.
