MSIX app attach, disks are mounted but shortcuts are not published
Hi Team, Till last two weeks all our MSIX app attach applications were working successfully. However, now we see the disks are mounted but the shortcuts are not published in start menu. In addition, for User 1 two app shortcuts are available out of 3 apps published, and for user 2 none of them are published. We did verify assignment in application groups and the state is active for the apps. Is there any pointers or log files we should be looking at to pinpoint the issue? We had raised an MS case, but no luck yet.
Windows Virtual Desktop, Lessons Learned from the Field
Today, at Microsoft Ignite | The tour 2020 in Prague, I'm presenting 2 sessions covering Windows Virtual Desktop and MSIX app attach. I'll share some of my lessons learned after doing a variety of different WVD deployments. In Prague? Join me: https://prague.myignitetour.techcommunity.microsoft.com/sessions/94813 https://prague.myignitetour.techcommunity.microsoft.com/sessions/94814
Is there a best practice for using packaged MSIX apps for AVD VHDs, w/driver dependent apps
Problem symptoms: "The problem we are running into is with Azure Virtual Desktop (AVD) using the feature MSIX App Attach. We have to unpack these MSIX files into a Virtual Disk, in this case a VHD. With testing, it just did not work right. File types would not open correct within the app itself. We did not really have the time to do some lengthy testing as we had to have a turnaround to deliver this app in AVD very quickly, so we opted to have it installed on the session hosts itself. The customer right now prefers we leverage MSIX App Attach for apps instead where possible." Initial recommended approach: "MSIX does not support drivers to be packaged in, it is intentional as the apps are supposed to be installed at a user level. What I would try is 1. see if there is a way to skip the driver's installation during packaging 2. package the app 3. later, on the user's machine, install the driver separately."WindowsAppRuntime 1.4 Failures in AVD Multi-Session – Event ID 404 Production Case
We recently experienced a production issue in an Azure Virtual Desktop multi-session environment that initially looked random — but turned out to be a shared framework instability amplified by scale. Environment: AVD multi-session host pools FSLogix profile containers MSIX App Attach Intune-managed Clean golden image Everything looked healthy. Yet packaged applications started failing across multiple host pools. Symptoms observed Users reported: Error 0x80070005 AppXDeploymentServer Event ID 404 WindowsAppRuntime 1.4 marked as NeedsRemediation Failures persisted after: Reboots Host redeployments Image rebuild This was not: A profile corruption issue An App Attach packaging issue An Intune deployment failure What actually broke Under session churn conditions (logoff / new session / runtime re-validation), WindowsAppRuntime 1.4 entered a NeedsRemediation state. Event Viewer showed: AppXDeploymentServer Event ID 404 HRESULT 0x80070005 Runtime file creation failure under WindowsApps Multi-session did not cause the issue. It amplified it. Shared framework registration timing under concurrent sessions made a rare condition systemic. Why multi-session exposed it In single-session environments, runtime inconsistencies remain isolated. In multi-session: Shared framework dependencies are reused Concurrent validation occurs Host pools recycle under load Registration timing becomes critical What would be a rare edge case became recurring instability. Remediation approach Instead of periodic polling, we moved to event-driven self-healing. Detection trigger: AppXDeploymentServer Event ID 404 Remediation logic: Restart AppXSVC Re-provision WindowsAppRuntime 1.4 Prevent concurrent duplicate execution Log execution We implemented a Scheduled Task: Monitoring Operational log Triggering immediately on Event ID 404 Running under SYSTEM Deployed via Intune Win32 package Detection logic validating task presence This converted reactive troubleshooting into automated correction across host pools. Architectural takeaway Multi-session environments amplify shared dependency weaknesses. WindowsAppRuntime is not “just another component” — it is a platform dependency. If the runtime layer drifts, everything layered above it collapses: MSIX App Attach Packaged apps Registration consistency Self-healing must be part of AVD design. For the structured technical case study (including deployment pattern and remediation logic), full write-up here: https://modernendpoint.tech/avd-multi-session-failure-analysis/ Has anyone else observed WindowsAppRuntime 1.4 entering a NeedsRemediation state under multi-session load? Curious if others saw correlation with specific Windows updates. — Menahem Suissa Modern Endpoint Architect
