Forum Widgets
Latest Discussions
Azure Virtual Desktop Regional host pools public preview open to all
Earlier this year we announced a public preview for a new type of host pool, referred to as a "Regional" host pool. This brings enhanced resiliency and increased options for data soverignty. Today we are expanding the public preview to everyone. A new drop down box called "Deployment Scope" will appear on the Basics tab of the Create a host pool deployment, when you choose a region that supports regional host pools in preview. At this point those regions are East US 2 and Central US. Further regions will be shortly added to provide even further choice. Ultimatley every Azure region where Azure Virtual Desktop is supported will be supported. Please deploy and connect to some new Regional host pools to test this functionality. Please refer to this blog post: https://techcommunity.microsoft.com/blog/azurevirtualdesktopblog/now-in-public-preview-azure-virtual-desktop-regional-host-pools/4474598 and the Microsoft Learn documentation: https://learn.microsoft.com/en-us/azure/virtual-desktop/regional-host-poolsAzure Virtual Desktop Application Group limit increase
We have increased the Azure Virtual Desktop limits to allow a higher number of Application Groups per tenant. We have doubled the limit to 1000 Application groups. This enable customers with a requirement for more app groups. Customers wishing for more than 1000 will still need to open a support ticket to get this reviewed All Azure Virtual Desktop limits are documented in the full Azure subscription and service limits, quotas, and constrains document: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#azure-virtual-desktop-service-limits
Windows App - you can't get there from here
Hi, Since moving to Windows App (The issue did not occur on the old Remote Desktop client), users when they come to do the 90 day forced SSPR (Company policy), it pops up with a message that you can't get there from here, its been baffling us for a while. However in the non-interactive log, it shows Windows App is instigating Microsoft Graph to do the password reset, and this shows as being blocked, we have excluded Azure Virtual Desktop client etc from the policy but you cannot exclude graph, like I said it seems the old Remote Desktop client didn't use Microsoft Graph to do this, but Windows App does. The only workaround we have is for the user to select sign out and sign in with a different account with the same credentials (Not ideal and it causing tickets to be raised) this method does not seem to use Microsoft Graph then, they have asked if they can go back to the old Remote Desktop Client which did not have the issue. Anyone else come across this or any permeant solution? Thanks
ResourceDeploymentFailure when creating a HostPool for Azure Virtual Desktop
When I try to create a Azure Virtual Desktop I get the following error: { "code": "DeploymentFailed", "target": "/subscriptions/a-b-c-d-e/resourceGroups/rg-avd-wcus/providers/Microsoft.Resources/deployments/HostPool-x-y-z-æ-ø-deployment", "message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.", "details": [ { "code": "ResourceDeploymentFailure", "target": "/subscriptions/a-b-c-d-e/resourceGroups/rg-avd-wcus/providers/Microsoft.DesktopVirtualization/hostpools/hp-avd-wcus/sessionHostConfigurations/default", "message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'." } ] } Anyone know what it is or how I can fix it? Subscription Subscription Microsoft.DesktopVirtualization = Registered Resource group Resource group Region = (US) West Central US Virtual network Region: (US) West Central US Key vault Region: (US) West Central US Pricing tier: Standard Access control (IAM): Gave myself Key Vault Administrator Key Vault → Objects → Secrets → Generate/Import Name: avd-admin-username Name: avd-admin-password AVD Host Pool Location: (US) West Central US Validation environment: No Preferred app group type: Dektop Host pool type: Pooled Create Session Host Configuration: Yes Load balancing algorithm: Depth-first Max session limit: 5 Session hosts Number of session hosts: 1 Name prefix: vm-avdwcus Location: (US) West Central US Availability options: No infrastructure required Secure type: Trusted launch virtual machine Image: Windows 11 Enterprise mulit-session, Version 25H2 Size: Standard D2as v5 Number of VMs: 1 OS disk type; Standard HDD OS disk size: Default size (128 GB) Virtual network: vn-avd-network-wcus Public inbound port: No Domain to join: Microsoft Entra ID Entroll VM with Intune: Yes
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.
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.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.
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.
