Packaging pipelines, strict mode enforcement, the "Pending" state fix that actually works, AppX vs MSIX decision matrix, and cross-platform delivery on AVD, Citrix CVAD, and Omnissa Horizon.
These two packaging formats cause constant confusion. Here's the ground truth for VDI environments in 2026.
| Property | AppX | MSIX | VDI Recommendation |
|---|---|---|---|
| File extension | .appx / .appxbundle | .msix / .msixbundle | Use MSIX for all new packaging |
| Introduced | Windows 8 / 2012 | Windows 10 1709 | — |
| Modification support | Limited | Full (modification packages) | MSIX modification packages let you layer config on top of base packages |
| App Attach compatible | Legacy support only | Full support | MSIX App Attach is the official name; AppX is old |
| Container format | ZIP-based | ZIP-based (same) | Can rename .appx → .msix if package manifest is compatible |
| Signing requirement | Required for sideload | Required (strict mode enforces) | Sign with internal CA or trusted publisher cert |
| Intune deployment | Supported (Win32) | Native MSIX app type | Use MSIX for Intune App Attach in AVD |
| VHD/CIM container | VHD only | VHD, VHDX, or CIM | Use CIM for AVD — faster mount, better SMB/Azure Files performance |
The packaging workflow that consistently produces clean, deployment-ready MSIX packages across Horizon, AVD, and Citrix environments.
# Sign MSIX with code signing cert
SignTool.exe sign `
/fd SHA256 `
/a `
/f "C:\Certs\CodeSign.pfx" `
/p "YourPassword" `
/tr http://timestamp.digicert.com `
/td SHA256 `
"C:\Packages\App.msix"
# Verify signature
Get-AuthenticodeSignature "App.msix" |
Select Status, SignerCertificate# Create VHDX then convert to CIM
New-VHD -Path "App.vhdx" -SizeBytes 500MB `
-Dynamic -BlockSizeBytes 1MB
Mount-VHD -Path "App.vhdx"
# Initialize, format NTFS, copy .msix to root
# Unmount, then convert to CIM:
cimfs.exe /create "App.cim" `
/imagepath "App.vhdx" /index 1The #1 complaint with MSIX App Attach. Apps stuck in "Pending" during logon. Here are the actual root causes and fixes — not the generic advice you've already tried.
The MSIX package container (VHD/CIM) isn't mounted before the user session starts. This is the most common cause — the App Attach service assigns packages but registration fails silently.
Verify the AppAttachStaging task completed before session logon. Check Event Viewer → Application and Services → Microsoft → Windows → AppXDeployment-Server. Error 0x80073CF0 = package not staged. Check share permissions — COMPUTER ACCOUNT needs read access to the MSIX share.
The signing certificate is not in the session host's Trusted Root or Trusted People store. Windows silently blocks registration with no visible error to the user.
Deploy signing certificate to Trusted Root Certification Authorities via GPO to all session hosts. If self-signed: also add to Trusted People store. Verify with: certmgr.msc on the session host.
The same package with a different version is already registered for this user from a previous session (common in non-persistent pools). MSIX won't register a new version over an existing one without deregistering first.
For non-persistent pools: ensure packages are fully deregistered at logoff. Check App Attach deregistration script fires on session disconnect (not just logoff). Use Get-AppxPackage -AllUsers | Where-Object Name -like "*AppName*" to inspect stale registrations.
Strict mode rejects unsigned or untrusted-signed packages at registration time. Error code: 0x80073CF3. Often the package was signed in QA but the cert wasn't propagated to prod session hosts.
Run Get-AuthenticodeSignature "App.msix" — status must be Valid. If "NotSigned" or "UnknownError", re-sign the package. Check if cert has expired. Check cert EKU includes Code Signing (1.3.6.1.5.5.7.3.3).
| Feature | Azure Virtual Desktop | Citrix CVAD | Omnissa Horizon |
|---|---|---|---|
| Native App Attach | ✓ Built-in (Azure Portal) | Via App Layering or manual | Via App Volumes 2512+ |
| Container format | CIM (preferred), VHDX, VHD | VHD, VHDX | MSIX via App Volumes 2512.4 |
| Storage backend | Azure Files Premium, Azure NetApp Files | SMB shares (DFS, NetApp, Pure) | SMB share, cloud storage |
| Strict mode enforcement | Policy: AllowAllTrustedApps = disabled | Via Citrix AppLayering policy | Via App Volumes ALM settings |
| Intune integration | ✓ Native (recommended) | Limited (Endpoint Manager only) | Not native |
| Per-user or machine | Per-user (App Attach) or machine (Intune) | Machine-level (layers) | Per-user (App Volumes) |
| Teams / O365 support | ✗ NOT recommended via MSIX | ✗ Use native install | ✗ Use native install |
Strict mode prevents unsigned or untrusted packages from registering. Essential for regulated environments and production AVD deployments.
# Enforce strict MSIX package signing policy
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Appx" `
-Name "AllowAllTrustedApps" -Value 0 -Type DWord
# Disable sideloading (non-Store, non-signed packages)
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Appx" `
-Name "AllowDevelopmentWithoutDevLicense" -Value 0 -Type DWord
# Verify App Attach service is running
Get-Service -Name AppReadiness | Select Status
# Check registered packages for current user
Get-AppxPackage -AllUsers | Where-Object {$_.PackageFullName -like "*AppName*"} |
Select Name, Version, @{N='Users';E={$_.PackageUserInformation}}# GPO Path:
# Computer Config → Admin Templates → Windows Components
# → App Package Deployment
"Allow all trusted apps to install" = Disabled
"Allow development of Windows Store apps" = Disabled
"Prevent non-admin users from installing packaged apps" = Enabled