Blog
App-V to MSIX App Attach: how to modernize application delivery for Azure Virtual Desktop
App-V Server support ended April 2026. Move .appv packages to App Attach first, then convert to MSIX in phases for Azure Virtual Desktop.
Table of Contents
- What ended for App-V in April 2026
- How App Attach replaces the App-V delivery model
- App Attach is the current feature; classic MSIX App Attach is deprecated
- Retiring the App-V servers first by running .appv packages in App Attach
- The App-V to MSIX conversion workflow
- Planning for the applications that will not convert
- How Nerdio Manager automates App Attach workflows in the App-V transition
- What this means for your App-V migration sequence
- Frequently asked questions about App-V to MSIX App Attach
Your App-V Management Server stopped receiving security patches on April 14, 2026. The App-V client inside Windows keeps running, but the server infrastructure streaming your packages is now unsupported software sitting in the middle of your application delivery path.
This App-V to MSIX App Attach guide is for end-user computing leaders and application delivery leaders who need to retire App-V servers first, then convert viable packages to MSIX in phases for Azure Virtual Desktop. For teams standardizing on Windows Cloud (Microsoft's umbrella for Windows 365 and Azure Virtual Desktop), the safe path is staged migration instead of a single cutover.
What ended for App-V in April 2026
App-V server components reached end of extended support before the client. Microsoft's App-V support policy puts App-V 5.0 and 5.1, along with the Management Server, Publishing Server, and Reporting Server, past their extended support end date on April 14, 2026. Microsoft no longer provides security patches for those components.
The client is a different story. As of November 2024, the Application Virtualization (App-V) client in Windows is no longer deprecated and persists with a fixed extended support lifecycle, according to Microsoft's deprecated features page. The App-V support policy adds that the feature: "is no longer being developed, and has moved to a fixed extended support lifecycle. As part of extended support, it will continue to ship as part of Windows, but requests to change product design or add new features aren't available." The sequencer sits in the same fixed extended support state, with no terminal date published for either.
That nuance does not make the server situation safe. CISA warns that "using software or hardware that is no longer supported by the vendor poses a significant security risk because new and existing vulnerabilities are no longer patched," and NSA/CISA red and blue teams list unsupported software among their top ten cybersecurity misconfigurations. In practice, the App-V server tier becomes a risk and control issue even when the client remains supported.
For regulated environments, PCI DSS treats unsupported technology as something requiring compensating controls until the technology is replaced.
Microsoft's App-V for Windows guidance points to the destination: "We recommend looking at Azure Virtual Desktop with MSIX app attach." App Attach changes the delivery model by removing the App-V server tier.
How App Attach replaces the App-V delivery model
App Attach removes the App-V server tier. Where App-V streams packages in real time from Publishing and Management Servers backed by SQL, App Attach mounts application packages from a Server Message Block (SMB) file share to user sessions through the Azure Virtual Desktop control plane. That shift takes dedicated application delivery servers out of the patching and decommissioning plan.
App Attach never installs applications on session hosts and never embeds them in golden images, so the same package can serve many host pools without adding to the image estate teams have to maintain.
Microsoft's App Attach overview lists .msix, .msixbundle, .appx, .appxbundle, and .appv as supported formats. Teams convert MSIX and Appx packages to disk images with the MSIXMGR tool, while App-V packages sit directly on the file share with no disk image conversion.
The delivery lifecycle runs through four phases. Stage and destage are machine-level operations at VM boot and shutdown; register and deregister are user-level operations at sign-in and sign-out. Disk images mount per VM using the session host's computer account, not per user. A session host opens one file handle per disk image regardless of active user count, and mounts images at boot even with zero users signed in.
At scale, the handoffs across file shares, package images, certificate trust, and host settings are where a management layer such as Nerdio Manager for Enterprise can reduce manual work without replacing Microsoft's App Attach model.
For disk image format, Microsoft recommends CimFS on Windows 11 based on measured performance in the App Attach overview:
|
Metric |
VHD |
CimFS |
|
Average mount time |
356 ms |
255 ms |
|
Average unmount time |
1,615 ms |
36 ms |
|
Memory consumption (8 GB host) |
6% |
2% |
|
CPU spike |
Maxed out multiple times |
No effect |
According to the App Attach overview (previously cited), operations teams can upgrade applications with a new disk image without a maintenance window, users can run multiple versions of the same application concurrently on one session host, and a single package serves multiple host pools.
Microsoft shipped two features with nearly identical names, App Attach and classic MSIX App Attach, and only one is the current feature.
App Attach is the current feature; classic MSIX App Attach is deprecated
App Attach and classic MSIX App Attach are distinct Azure Virtual Desktop features. App Attach is the current path. The GA announcement put App Attach general availability on June 13, 2024; Microsoft deprecated the classic MSIX App Attach feature on June 1, 2025, then removed its documentation in June 2025 and replaced it with App Attach content. The two features use different assignment models, which changes how teams provision access.
The GA feature changed the assignment model. Per the announcement, "applications can now be assigned per user, both within a desktop session and remote app sessions," and "application groups are no longer required to assign users to app attach apps, significantly simplifying assignment and reducing the number of application groups needed."
Classic MSIX App Attach gated access through Desktop or RemoteApp application groups. True per-user assignment exists only in the newer feature.
On April 14, 2026, the same day App-V Server support ended, Microsoft announced App Attach support for Windows Server 2025 and Windows Server 2022 session hosts, another capability the classic feature never received.
Teams that evaluated MSIX App Attach a year or two ago and set it aside were looking at the classic feature. The current App Attach can use existing packages immediately, which changes the migration math for App-V shops.
Retiring the App-V servers first by running .appv packages in App Attach
Existing .appv packages can move into App Attach without conversion, which gives teams the fastest available risk reduction. App Attach natively supports the .appv format, and Microsoft's support policy (cited previously) is explicit: "App-V app attach allows you to use your App-V packages with Azure Virtual Desktop without needing to run your own server."
A Microsoft Tech Community post on life after App-V Server confirms this path requires "no DC or SQL server" dedicated to application delivery.
App-V packages sit directly on the SMB file share, so the MSIX disk-image step disappears. They do not require a disk image.
The App Attach prerequisites are a file share in the same Azure region as your session hosts with read access for session host computer accounts, and session hosts joined to Microsoft Entra ID or Active Directory Domain Services. Microsoft Entra Domain Services is explicitly not supported.
Azure Files guidance ties file share tier to concurrent user count:
- Fewer than 400 concurrent users: HDD pay-as-you-go file shares.
- 400–1,000 concurrent users: HDD provisioned v2, or multiple HDD pay-as-you-go shares.
- 1,000–2,000 concurrent users: SSD, or multiple HDD file shares.
Storage planning also depends on package volume and concurrency. Teams can follow our Azure Files storage sizing guidance when modeling file share capacity.
App Attach has no separate license fee. App Attach is included with Azure Virtual Desktop at no separate fee. Eligible licenses include Microsoft 365 E3/E5/E7, F3, Business Premium, and Windows Enterprise E3/E5, with storage billed at standard Azure Files rates.
Running .appv packages in App Attach decouples the two halves of the migration. The unsupported server infrastructure can come down before any MSIX conversion begins, and MSIX conversion then proceeds on the team's own schedule. One configuration dependency to plan for: session hosts consuming .appv packages need the App-V client service enabled, so image and host-pool planning should account for that.
The App-V to MSIX conversion workflow
Once .appv packages are running through App Attach and the servers are gone, the conversion workflow moves each package through four stages: gating by App-V version, running the MSIX Packaging Tool, signing the resulting package and trusting the certificate chain on every session host, and creating a disk image that passes four-phase testing.
Working through those stages in order is what keeps user acceptance testing from surfacing avoidable defects.
Teams typically start by separating App-V 5.1 packages from App-V 4.x packages, because the package version determines the conversion path.
1. Gating the work by App-V version
Your App-V version decides the conversion path. For App-V 5.1 packages, the MSIX Packaging Tool offers a direct path per Microsoft's conversion documentation: "all you need to do is specify an App-V file, and you get fast tracked to the create an MSIX page."
For App-V 4.x, Microsoft recommends repackaging from the source installer; packages from App-V 4.6 SP2 or earlier must first convert to .appv format via the PowerShell Package Converter. Even for 5.1 packages, repackaging from the original installer is often cleaner when the installation recipe is known, because it avoids conversion artifacts.
2. Converting with the MSIX Packaging Tool
The MSIX Packaging Tool requires Windows 10 version 1809 or later, administrator privileges, and a conversion environment matching the deployment target architecture. Microsoft's pre-configured Hyper-V Quick Create VM gives teams a clean packaging environment for that work. For estates with dozens or hundreds of packages, App-V 5.x conversion runs from the command line with an XML template:
MsixPackagingTool.exe create-package --template c:\users\documents\ConversionTemplate.xml -v
A Microsoft-published batch script (batch_convert_appv.ps1) drives the tool across multiple packages using template fields for installer path, save location, and package metadata.
3. Package signing and certificate chain trust
Signing is mandatory. Windows requires MSIX packages to be signed with a valid code signing certificate carrying object identifier 1.3.6.1.5.5.7.3.3, and the certificate used to sign the MSIX package must be installed on every session host.
Per the App Attach overview (cited previously), Microsoft requires an internal enterprise or standalone certificate authority for production, and self-signed certificates are test-only. The default certificate generated by Azure Key Vault will not work for code signing. Distributing certificates across large session host fleets is one of the least-documented pain points in the workflow.
4. Disk image creation and four-phase testing
MSIX packages become CIM or VHDX images via MSIXMGR:
msixmgr.exe -Unpack -packagePath "C:\msix\myapp.msix" -destination "C:\msix\myapp\myapp.cim" -applyACLs -create -fileType cim -rootDirectory apps
One compatibility trap: CIM files should be generated on a Windows version lower than or equal to the target deployment version, so a CIM built on Windows 11 may not work on Windows 10. The storage account should stay in the same region as session hosts; VHD mounts must stay under the 400 ms threshold. Operations teams can then validate all four lifecycle phases in order, stage through destage, before any production assignment.
Even packages that convert cleanly can carry defects into user acceptance testing. Documented failure modes include user settings that do not migrate (App-V stores them in %APPDATA% and HKCU, while MSIX uses containerized storage), and file type associations or context-menu entries that require manifest work.
The Package Support Framework applies runtime fixes for many of these, and the latest MSIX Packaging Tool release (1.2024.405.0) expands its fixup coverage.
Remediation time should be budgeted per wave. Some applications will need another delivery model.
Before production waves begin, blocked applications should have their own plan instead of stalling packages that can move cleanly.
Planning for the applications that will not convert
MSIX compatibility has improved sharply but is not universal. Microsoft documents hard blockers that still require another delivery path, so some packages need fallback planning before conversion waves begin.
The blockers appear across Microsoft's MSIX packaging guidance:
- Drivers. "MSIX does not support drivers." Kernel-mode driver dependencies, common in licensing and integrity services, fail outright.
- Per-user Windows services. MSIX doesn't support per-user Windows services and supports only session-0 per-machine services. Packages that include services require admin elevation to install.
- In-process shell extensions. Modules loaded in-process by external executables are unsupported, a real loss for apps with context menu integrations.
- Elevation requirements. Apps requiring elevated execution will not run correctly for standard users.
- WinSxS dynamic linking and externally exposed GAC assemblies. WinSxS dynamic linking is not supported, and externally exposed GAC assemblies are documented non-starters.
For blocked applications, four fallback paths cover the estate. The app can be baked into the golden image when it needs drivers or system-level access. Teams can deploy through Microsoft Intune Win32 in device context. Microsoft cautions that "Azure Virtual Desktop RemoteApp and MSIX app attach aren't currently supported in Microsoft Intune."
FSLogix Application Masking can hide image-installed apps from user subsets, which requires AD DS or hybrid-joined hosts because the rule sets query a domain controller over LDAP. The package can also remain as .appv in App Attach while the App-V client remains supported under its fixed extended support lifecycle.
Triage should happen before conversion waves begin. Teams can inventory the estate, retire what nobody launches, flag the driver-dependent and elevation-requiring apps for fallback paths, and run everything else through the pipeline in waves. That triage-and-wave motion is exactly the work that gets punishing at scale without tooling.
How Nerdio Manager automates App Attach workflows in the App-V transition
Nerdio Manager centralizes much of the App Attach workflow that native tooling can spread across MSIXMGR, PowerShell, certificate management, and Azure portal tasks.
Its Unified Application Management consolidates WinGet apps (public and private repositories), MSIX App Attach, Microsoft Store, Microsoft Intune, and custom line-of-business installers into a single catalog with policy-based deployment, while teams manage App Attach packages through a separate App Attach workflow.
For the App-V to MSIX motion specifically, Nerdio Manager covers the friction points this article has walked through:
- App Attach and image work without manual scripting. Nerdio Manager supports MSIX App Attach in application management workflows and uses desktop orchestration to replace manual scripting for image work.
- Desktop orchestration. Desktop orchestration and rollback replace manual scripting for the images that still carry baked-in apps.
- Deployment visibility. Step-by-step install logs and near real-time reporting replace binary success-or-fail signals.
An independent benchmark by Dr. Benny Tritsch measured the time and click reduction. Updating a custom image took 37 seconds and 13 clicks with Nerdio Manager versus 5 minutes 9 seconds and 146 clicks natively: 88% less time, and fewer clicks mean fewer manual steps where configuration errors can happen. TechTarget's Enterprise Strategy Group, in a September 2024 economic validation, found Nerdio Manager cut the IT hours needed to manage Azure Virtual Desktop by approximately 50%.
The same application catalog also covers Intune-enrolled Windows devices. Unified Application Management deploys applications to Intune-enrolled Windows devices, including Windows 365 Cloud PCs, and reports deployment status in near real time instead of waiting on native Intune reporting.
On the Windows 365 side, Nerdio Manager's value centers on Intune management, application delivery, and Cloud PC lifecycle operations: applications reach Cloud PCs in about 30 seconds versus native Intune delivery that can take up to 3 hours, and Nerdio Advisor surfaces right-sizing recommendations, license reclamation alerts, and Flex (previously Frontline) license conversion recommendations. Many enterprises run both Windows 365 and Azure Virtual Desktop, and a common application catalog cuts duplicate app-management work across the Windows Cloud estate.
What this means for your App-V migration sequence
The migration sequence starts with the unsupported server risk. The first step is to move existing .appv packages onto an App Attach file share and decommission the Management, Publishing, and Reporting Servers that stopped receiving patches in April 2026. That single step removes the unsupported infrastructure the intro named, with zero repackaging effort.
The second step is to convert packages to MSIX in prioritized waves, gated by App-V version and validated through all four lifecycle phases. The third step is to route applications that will not convert to golden image, Intune Win32, or FSLogix masking, or leave them as .appv on the fixed-support client.
Manual App-V-to-MSIX migrations without purpose-built tooling can become an extended, manual backlog. The Nerdio Manager platform can reduce the manual image, packaging, and deployment steps that stretch App-V-to-MSIX migration projects. Carvana reported a fully functional Azure Virtual Desktop deployment with Nerdio Manager in 14 days, alongside a 40-50% cost reduction compared to its previous platform. With that tooling in place, the conversion work becomes a managed backlog.
If App-V Server end of support is forcing your application delivery decision, you can see the workflow in your environment. You can get a demo to see how Nerdio Manager handles App Attach packaging workflows and image orchestration across your Windows 365 and Azure Virtual Desktop environment, or try it free in your Azure tenant.
Frequently asked questions about App-V to MSIX App Attach
Resources
Learn more about Nerdio Manager
