Problems with FSLogix 3.26 - W11 MU - 10 users per Vm
Scenario Overview We are documenting a recurring intermittent Denial of Service (DoS) regarding user profiles in an AVD multi-session environment using Azure Files Premium (SMB). The issue consistently surfaces after updating to the FSLogix 3.26 branch (v3.26.126.19110). Root Cause Analysis (Failure Logs) Through deep log analysis, we identified a "driver poisoning" pattern unique to version 3.26: SMB/Kerberos Handshake Sensitivity: Under varying storage response times (latency spikes of ~350ms vs. the usual ~40ms), version 3.26 triggers an intermittent 1326 error (Logon failure: unknown user name or bad password). Driver Execution Flow Corruption: Unlike previous versions, after this initial network/authentication glitch, the 3.26 driver fails to release execution threads or volume handles properly. Catastrophic Failure (Error 267): The system attempts to access the SecuredProfileRegData path within the mounted VHDX, but the driver returns Event ID 26: "0x10b - The directory name is invalid". Unrecoverable "Zombie" State: Once Error 267 occurs, the VM becomes "poisoned." It blocks all subsequent login attempts and even prevents a clean uninstallation of the agent (MSI Error 0x80070643 due to files being "in use"), necessitating a full VM reboot or redeployment. Has anyone else been through this? My first step was to go back to Agent Version 2506 (2210 Hotfix 4) Evidence of Success with Version 2506 (2210 Hotfix 4) After performing a clean deployment and reverting to version 3.25.626.21064, metrics from April 24, 2026, show absolute stability on the same infrastructure: Consistent Logon Times: Average profile load time of 1.6 seconds across multiple concurrent users Storage Efficiency: FindFile response times remained stable between 39ms and 45ms, with the agent successfully retrying any momentary delays. Error Resilience: Unlike v3.26, if this version encounters an authentication glitch (e.g., on a local service account), it bypasses the error and remains functional, allowing domain users to log in without collateral blockages. Concurrency Support: Seamlessly managed over 20 simultaneously mounted volumes without pointer collisions or kernel hangs.
Feature request: allow setting web client features from direct-launch-url
We use the "direct launch URL" feature of the AVD web client to deep link users to a session desktop (https://learn.microsoft.com/en-us/windows-app/direct-launch-urls?tabs=avd). One of the reason we use the web client is because we use AVD in exam halls on Chromebooks in kiosk-mode. The ChromeOS kiosk-mode only supports websites. Students are faced with a connection dialog in which they can toggle IME and Special Keys. The students have to enable IME, but since these are university-owned devices, they do not know and just click "Connect". We would like to be able to configure these client options automatically. For example, as query parameters in the direct-launch-url. Ideally, we would also skip the "Connect" dialog entirely and just go strait into the session once the direct-launch-url is loaded.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 ArchitectImproper AVD Host Decommissioning – A Practical Governance Framework
Hi everyone, After working with multiple production Azure Virtual Desktop environments, I noticed a recurring issue that rarely gets documented properly: Improper host decommissioning. Scaling out AVD is easy. Scaling down safely is where environments silently drift. Common issues I’ve seen in the field: Session hosts deleted before drain completion Orphaned Entra ID device objects Intune-managed device records left behind Stale registration tokens FSLogix containers remaining locked Defender onboarding objects not cleaned Host pool inconsistencies over time The problem is not technical complexity. It’s lifecycle governance. So I built a structured approach to host decommissioning focused on: Drain validation Active session verification Controlled removal from host pool VM deletion sequencing Identity cleanup validation Registration token rotation Logging and execution safety I’ve published a practical framework here: The framework is fully documented and includes validation logic and logging. https://github.com/modernendpoint/AVD-Host-Decommission-Framework The goal is simple: Not just removing a VM — but preserving platform integrity. I’m curious: How are you handling host lifecycle management in your AVD environments? Fully automated? Manual? Integrated with scaling plans? Identity cleanup included? Would love to hear how others approach this. Menahem Suissa AVD | Intune | Identity-Driven Architecture
RemoteApp for Word/Excel with Google Drive
I want to set up RemoteApp so users can use Word and Excel remotely. At the same time, I want them to be able to access and save files directly from Google Drive within those apps. We currently only have 3 users who need this, but we plan to expand in the future. What’s the best way to do this? Do I need a specific setup, plugin, or service to make Google Drive work seamlessly with Word/Excel in a RemoteApp environment?Need Help: Shortpath Drops & RDstack error in AVD
I’m seeing persistent AVD connection issues and would appreciate guidance. Frequent ShortpathTransportNetworkDrop (68) and ShortpathNetworkDrop (16644) errors GetInputDeviceHandlesError (4463) US based users and hostpool/sessionhost Users experience instability and degraded performance
Mouse Click Offset Issue in Azure Virtual Desktop App on Windows 11 with Dual Monitors
We are experiencing a recurring mouse misalignment issue when using the Azure Virtual Desktop (AVD) Windows App on several Windows 11 clients. The problem occurs on devices with two external monitors and affects multiple users. Environment Windows version: 10.0.26200.6899 (Windows 11, 25H2) AVD Windows App: mainly version 2.0.757.0, some clients are on slightly different versions Hardware: Windows 11 PCs with two external monitors Display settings: both monitors at 1920x1080, 100% scaling Mac users (using the AVD app) report no issues Issue description The visual mouse pointer and the actual click position become misaligned inside the AVD RemoteApp session. For example, clicking on one item may select the item below it. This appears to be a rendering or coordinate-mapping issue within AVD when running inside the Windows App. Temporary workaround Minimizing the AVD window and then maximizing it immediately resolves the issue. This refresh/redraw action realigns the pointer and click coordinates. Questions Has anyone else seen mouse click offset issues in the AVD Windows App on Windows 11 25H2 with dual-monitor configurations? Are there known fixes, configuration adjustments, or recommended workarounds beyond the minimize/maximize redraw?
AVD RemoteApp disconnects after sleep — any way to mimic Citrix Session Reliability?
In Azure Virtual Desktop (AVD), whenever my laptop goes into sleep/hibernate and I wake it up, my RemoteApp disconnects and throws an error. With Citrix, the session stays “alive” because of Session Reliability, but AVD doesn’t seem to handle this the same way. I’ve already set session timeouts and keep-alive settings via RDP properties/GPO, but the problem isn’t policy-related — it’s triggered by the local device going to sleep and dropping the network. I have full permissions to configure and manage host pools, session hosts, and RDP properties. Is there any way to mimic Citrix’s behavior (Session Reliability / seamless resume) so users don’t get disconnected after sleep? Or is this simply a limitation of the AVD client?
Windows App Application Protection Policy
I have been testing out an Intune MAM policy to restrict copy/paste and drive redirection to AVD session hosts based on the link here: https://learn.microsoft.com/en-us/windows-app/require-device-security-compliance-intune?tabs=web#related-contentHowever, I've run into problems (in two separate tenants) that have halted me from being able to test. Setup Intune App Protection Policy targeting Windows Devices & Microsoft Edge\ Conditional Access Policy enforcing App Protection Policy when users access 'Azure Virtual Desktop' target resource via https://windows.cloud.microsoft.com Results First When signing into a user account targeted by the policy, they are prompted to Switch Edge Profile which signs in the user to a new Edge profile for 'Work or School Account'. The account has to sign in again. The account can access Windows App resources When launching a desktop session, this authentication page pops up for an account "local@debugonly" Second When signing into a user account targeted by the policy, they are prompted to Switch Edge Profile which signs in the user to a new Edge profile for 'Work or School Account'. The account has to sign in again. After sign in, the account loops with 'Switch Edge Profile' and gets stuck here I'm curious if anyone has gotten this to work and what was your setup? Or if Microsoft or provide some assistance or if this is in the wrong forum, any help would be appreciated.
