Forum Widgets
Latest Discussions
Print Spooler on AVD hosts doesn't start when booted up
This just came about today, any host that was turned on via Nerdio the print spooler was off. All these hosts were provisioned on Oct. 7 and haven't had this issue until today. Azure issue? AVD issue? We've changed nothing configuration wise that would cause this, no new patches either. These are 16vCPU boxes, with 64GB of RAM, again only happened today and we've been running this image since Oct 7th without issue and AVD since July in prod. Print Nightmare patches are installed.
Windows App iOS RemoteApp Won't Reconnect
We are building a RemoteApp environment using AVD for the session hosts. On iOS, what happens is the screen powers off/device goes to sleep. When a user logs back into the iPad, the RemoteApp was still the focus, so they see buttons to reconnect or disconnect. If we press reconnect, it will either spin endlessly OR it will report an error on reconnection attempt. If we then close the error OR if we press disconnect where it drops us into the Windows App, then reopen the exact same Windows App it immediately reconnects. This does not happen in Windows at all, we have no Android deployments to test, and are trying iOS deployments on iPad and troubleshooting with iPhones. Both device types experience the issue. To troubleshoot, I've tried multiple iOS devices by multiple users; same problem. Those same users connecting to our AVD desktops, not RemoteApps, reconnect without issue. Our AVD and RemoteApp session hosts all use the same Group Policies and are, at this point, only domain joined, not Entra or Hybrid. Any thoughts on why this happens? Would logs be helpful?Windows App expands auto logoff support to managed Android devices (Public Preview)
We're excited to announce that Windows App auto logoff on Android is now in public preview, giving administrators a simple, Mobile Device Management (MDM)–configured way to keep shared devices clean between sessions. Already available on Windows, auto logoff now extends to MDM-enrolled Android devices, a key step toward enabling frontline and shared-device scenarios on Android hardware. What is auto logoff? Windows App auto logoff on Android is an admin-configured setting that signs the user out of Windows App and removes locally stored app data when the app is closed, disconnected, or left inactive for a configured period. By removing locally stored app data, auto logoff helps ensure that every session starts with a clean state when users sign in with their own credentials. It's designed for operational convenience and device hygiene — not as a security boundary — and it does not interrupt active Azure Virtual Desktop or Windows 365 sessions. Only the local Windows App state is reset. Why it matters for shared devices Auto logoff is ideal for shared-device deployments where Windows App is the primary app users interact with to access Azure Virtual Desktop or Windows 365: Clean handoffs: when one worker finishes and closes the app, the next person signs in fresh Local Windows App data is removed automatically: cached app data is cleared when configured logoff conditions occur (app close, disconnect, or inactivity) Streamlined re-entry: an optional setting skips the onboarding and privacy screens after logoff, so shared agreements are accepted once per device rather than by every user Flexible triggers: reset on app close, sign-out, remote-session disconnect, or after a defined period of inactivity How to configure it Windows App auto logoff on Android is set from your MDM admin console (for example, Microsoft Intune) via a managed app configuration profile assigned to Windows App. Core settings include: Enable auto logoff: the master switch (off by default) Inactivity timeout: minutes of idle time (with the screen locked) before Windows App signs out and resets; set to 0 to rely only on close/disconnect triggers Skip first-run experience: recommended for shared devices so users aren't re-prompted through setup The setting names and value types are the same across MDM providers, only the admin UI differs. Prerequisites Windows App version 11.0.0.113 or later on a supported Android device The device enrolled in your MDM, with Windows App installed as a managed app Admin access to a supported MDM provider that can deliver app configuration to Windows App Note: Inactivity-based auto logoff depends on the Android device’s screen lock setting. If a device is configured never to lock, the inactivity timer won't fire (close, sign-out, and disconnect triggers still work). Learn more For the full setup walkthrough, configuration examples, and known limitations, see Configure auto logoff for Windows App on Microsoft Learn. We'd love to hear how you're using auto logoff for your shared-device and frontline deployments, drop a comment below and let us know what scenarios you'd like to see us light up next.
Windows OS edition validation error
In one of my session hosts, the windows operating system version & edition has different values, On winver.exe" --> it gives Windows 11 multisession 22h2 whereas in registry, path to HKLM:\Software\Microsoft\Windows NT\CurrentVersion\ Keyname: ProductName Value; Windows 10 multisession Can someone experience this in similar, .. Thanks, RajkumarCopy/Paste not working
Hi there i am using windows App on a MacBook Pro M3 and i am using Windows App to connect to a remote server, i have the clipboard settings on bidirectional but i am not able to copy and paste from local to remote as well as remote to local and it does not work at all, i am on Mac OS 15.0.1 (24A348) please look into this. Kind Regards,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.
Windows App - RDP channel crashes when printing on a redirected canon printer
Hey team, I would like to know, if anyone else struggles with the following scenario: A canon printer is installed on a local client. The user is working in the AVD environment. The printers are redirected into the AVD-Session via "printer redirect". Since the users are migrating to the new "Windows App", the AVD session breaks as soon as the user is printing on a redirected Canon-Printer. When printing on another printer, there is no issue. Also: With the "Microsoft-Remotedesktop" Application, everything works as it should. A Microsoft ticket is already raised. I would like to know if there are other environments, which are encountering the same issue.
Built-in Appx Apps authentication and FSLogix
Hi, What is the state of play with Built-in Appx applications and FSLogix? We have a customer who we migrated to Windows 11 Multi-Session, EntraID only, Intune and Cloud Kerberos for FSLogix profiles. They have a strange issue that they use some of the built-in Appx applications, The Microsoft To Do app and Sticky Notes. When they open the app for the first time it logs in straight away, no issues. They close it and load it, all fine. Come to log off the session host and log back on, load the appx app, it struggles to auto sign in, both apps have the same issue, you can click a few times and it logs in, but does this every time. If we disable FSLogix, and use local profiles, it works. If we enable Roam Identity, it works (We have disabled this as I know we cannot use it) I have built a brand new session host, Removed all Intune polices apart from setting FSlogix settings, same issue, Latest FSLogix, Taken away ODFC and reset profile, same issue. Are Built-in Appx supposed to work. Just seems to be really bad at this stage if they don't, Latest FSLogix, set InstallAppxPackages to 1, (default anyway) Am I missing anything, is this supposed to work now? I would have thought this would be fine? If anyone is able to provide any assistance would be greatly appeciated. Thanks.Where is storage sense on Windows 11 22H2 AVD image?
I am toying with deploying windows 11 to our AVD environment, but we use Onedrive and rely on storage sense to keep the profiles semi-clean. With windows 10 22h2 and Windows 11 on hardware, the storage sense service is there, but it does not appear to be on the AVD deployments. How does Microsoft intend for us to keep our user profiles clean and clean up crud accumulated in the fslogix profiles?Installing and configuring Windows App on Thin Client environments
I am seeking technical guidance on accessing the new Windows App from Thin Client environments, following the end of support for the Microsoft Remote Desktop client (27 March 2026). Current Environment End-user devices: Thin Clients used by customers Thin Client OS types in use: Windows 10 IoT Enterprise, and/or Thin Clients running custom NComputing firmware Backend environment: Windows Server–based environment hosting a line-of-business application (accessed via RDP / RDS) Current Access Method Users currently connect using the Microsoft Remote Desktop (RDP) client, accessing either: A full desktop session, or Published RemoteApps via RDS This setup is functioning today but is impacted due to Remote Desktop app end of support. Issue / Challenge Microsoft is recommending migration from Remote Desktop app to the Windows App. However, during evaluation, we are facing blocking limitations on Thin Client devices, specifically: Windows App is not supported / cannot be installed on: Windows 10 IoT–based thin clients, and Thin clients running custom NComputing firmware These devices have: Limited hardware resources Restricted OS / firmware‑level constraints No support for installing modern Store / Windows App packages As a result, users cannot access the environment using Windows App, creating a risk of service disruption. What We Need : We request Microsoft’s official technical and product guidance on the following: Confirmation Is the Windows App officially supported on: Windows 10 IoT Enterprise? NComputing or other firmware‑based thin clients? Alternative Supported Options Are there supported alternatives for thin clients after Remote Desktop app end of support: Web-based access? Legacy RDP components still supported for Windows Server? Specific RDS client versions approved for IoT devices? Best‑Practice Architecture Recommended Microsoft‑supported architecture for: Thin client environments RDS / RemoteApp access Scenarios where Windows App installation is not possible Risk & Compliance Clarification Guidance on continued use of RDP clients in end-of-support but still operational mode, and Associated security or compliance implications, if temporary continuation is required. This information is critical to ensure business continuity for customers who cannot upgrade thin client hardware or firmware immediately.
