MSIX packaging with no original installer, for Intune, AppAttach, and Cloud PC delivery.

Windows 10 support ended in October 2025. Intune defaults to modern deployment paths, and Azure Virtual Desktop AppAttach requires MSIX. The migration window has compressed from years into months for most teams, and MSIX is the format that lands across Intune, AVD AppAttach, and modern Cloud PC delivery alongside IntuneWin.

Yes. Capture-first means no installer media dependency. EtherApps Forge captures the installed application footprint from a live system (files, registry, AppData, services, and dependencies) and produces signed MSIX, MSI, IntuneWin, and AppAttach outputs from one capture. This is the main reason teams pick EtherApps Forge over traditional packaging toolchains for legacy estates.

Yes. One capture produces signed MSIX for Intune, IntuneWin for legacy-path Intune deployment, and MSIX AppAttach for Azure Virtual Desktop. Windows 365 delivery uses MSIX or IntuneWin from the same capture. Windows 365 does not currently support AppAttach, so Cloud PC delivery goes via the MSIX or IntuneWin path.

No. AI-guided routing augments the team by closing the MSIX skills gap and suggesting the right path per application, but a human reviewer still signs off on each package. EtherApps Forge works alongside existing packaging workflows rather than replacing packager judgement.

App-V 5.1 packages can be converted directly with the Microsoft MSIX Packaging Tool, through the interface or the command line for batch runs. App-V 4.x packages are not supported directly; Microsoft recommends converting from the source installer, and where the installer is lost a capture-first repackage from a live installation is the practical route. EtherApps Forge covers that capture-first path with human review before release.

The usual blockers are launch and logoff scripts, runtime behaviours that assumed the App-V client, middleware dependencies, and packages whose source media no longer exists. The Package Support Framework fixes many runtime gaps after conversion, and packages that resist direct conversion can be repackaged capture-first instead. A short assessment pass before migration finds these blockers early.

Yes. Every MSIX package must be signed with a certificate the estate trusts before Windows will install it, so plan certificate handling as part of the migration workflow rather than an afterthought. EtherApps Forge builds signing into the packaging pipeline, and the same certificate discipline applies to packages converted with Microsoft tooling.

Assign the signed MSIX packages through Intune like any modern Windows app, starting with a pilot ring on representative Windows 11 devices before broad assignment. Keep the App-V package available until the pilot proves the converted app behaves correctly, then retire the old delivery path as each wave completes.

The Package Support Framework is a Microsoft open-source runtime that corrects behaviour applications rely on but cannot perform inside the MSIX container. The common cases are writing files next to the executable, expecting a fixed installation path, or reading machine registry locations the container redirects. EtherApps Forge stages the framework as part of packaging, applying file and registry redirection and working-directory fix-ups, so a captured legacy application runs correctly with no change to its source code.

Yes. The forge_msix CLI is a drop-in replacement for Microsoft's makeappx.exe, calling the same Windows packaging engine, so a build folder becomes a signed, validated MSIX using the switches an existing pipeline already passes. Developers and ISVs can scaffold a manifest from the built executable, create and sign in one step, validate the result, and smoke-test it, all as stages in a release pipeline rather than as a manual step after the build.

Microsoft moved the App-V client and sequencer to fixed extended support, so they still ship with Windows but receive fixes only, and support for the App-V server components ended in April 2026. Teams already using App-V packages on Azure Virtual Desktop can use App-V app attach without an App-V server, and most estates are using this window to plan a controlled App-V to MSIX migration.

ClickOnce installs into a per-user profile location with no admin rights and no isolation from the rest of the machine, aimed at self-updating line-of-business apps a developer publishes directly. MSIX installs into a sandboxed container with file and registry virtualisation, a clean uninstall, and Intune/AVD AppAttach delivery built in. ClickOnce suits a small in-house app with its own update channel; MSIX suits estate-wide packaging where IT needs consistent deployment, clean removal, and centralised management.

MSI installs directly onto the machine and modifies shared locations (Program Files, the registry, shared DLLs), so two MSI-installed apps can conflict with each other over time. MSIX containerises each app with its own virtualised file and registry namespace, so installs stay isolated and side-by-side versions and clean uninstalls both become reliable. The trade-off is that some legacy MSI-installed apps rely on writing outside their own container (a shared plugin folder, a fixed install path another app expects), which is exactly what the Package Support Framework's file and registry redirection is built to fix during MSIX packaging.

App-V is Microsoft's older application-virtualisation format, now on fixed extended support with server-side support ended April 2026, and it needs its own client or App-V AppAttach on Azure Virtual Desktop to run at all. MSIX is the current Windows packaging format, works natively with Intune deployment and AVD/Windows 365 AppAttach with no separate client, and is what Microsoft's own tooling and MSIX Packaging Tool build toward now. A new packaging project should target MSIX; App-V is a migration-source format at this point, not a target.

There is no single button that safely converts a whole estate at once, because each application's dependencies and install behaviour differ. What actually scales is running the same capture-first workflow repeatably: EtherApps Forge captures one running application's real footprint, routes it through AI-guided packaging decisions for signing and manifest fix-ups, and outputs MSIX, MSI, IntuneWin, or AppAttach, then the next application follows the identical path. An estate gets through faster because every app takes the same repeatable route, not because one operation converts them all unattended.

Intune deploys both, so the choice comes down to the application, not a blanket rule. MSIX gives clean uninstall, no leftover files or registry keys, and works with AVD/Windows 365 AppAttach; that makes it the default for anything going through a packaging refresh. A Win32/LOB app stays the right call when an application genuinely cannot be containerised without breaking it and no MSIX fix-up closes the gap. When in doubt, package as MSIX first and fall back to Win32 only for the specific applications that need it, rather than deciding format estate-wide up front.

The conversion itself is the same work as any other App-V-to-MSIX migration: Forge captures the running application and produces a signed MSIX or MSI. What changes for a Citrix estate is the delivery step, and it's a native one, not an extra tool: Citrix Virtual Apps and Desktops and Citrix DaaS support MSIX and MSIX app attach directly on session hosts. So the output from a Forge capture goes straight into Citrix's own app-packages feature.

Yes. Parallels RAS 19 and later natively delivers MSIX packages and MSIX app attach, extended to VDI in 19.1 and to AVD in 19.2. A signed MSIX from Forge imports directly into Parallels RAS's application packages feature, so modernising an App-V or MSI app for a Parallels RAS estate doesn't need a separate packaging route from any other MSIX target.

Yes, and it should be a clean one. Microsoft's MSIX Packaging Tool expects a clean Windows machine or a Hyper-V virtual machine so the capture does not pick up leftover state from an engineer's daily desktop. EtherApps Forge applies the same principle through a controlled virtual machine inside your own Azure environment: every capture starts from a known-good image, so the package is repeatable and audit-ready rather than shaped by whatever happened to be installed. It also removes the manual rebuild of a packaging VM between applications, which is where most of the elapsed time goes on a Windows 11 packaging backlog.