Forum Widgets
Latest Discussions
Secondary mailboxes and FSLogix Roam Identity
HI, Got a bit of a puzzler, so we have a client who uses outlook to access the main mailbox on the tenant, but they also have a secondary mailbox added to outlook from a different tenant, so when they log in it authenticates to both, all good. The reason they have it set up this way is to do with signatures. With existing FSLogix this works fine, we then upgraded them to the latest, this changes the authentication method and puts the token on EntraID, the secondary mailbox now wants the password every time, as its on another tenant. Makes sense, so enabled Roam Identity to put back status quo. However this then pulls the machine out of EntraID/Intune, and recommendations is not to use Roam Identity if enrolled into Intune. Anyone else come across this or any way forward/guidance, have about 50+ users set up this way? Thanks
Your computer was unable to connect to the remote computer
I'm Having this AVD issue with a new workspace that was setup. It's a SessionDesktop application with a hostpool. The Web version of the client works fine, can connect and open RDP session but the Windows App will not work either on-prem or off-prem showing the error in the title when attempting to launch the session. I have tried playing with every setting I can find from RDP Properties, to Network ones, RDP shortpath, Entra SSO, Cred SSP, etc. Even if there was some sort of on-prem network issue it should still work when off-prem and it doesn't. But the web client works fine so I can't figure out what would cause this. The Application is just "SessionDesktop" and has no configurable parameters other than Display Name. The Host Pool has a private endpoint and when attempting to launch from the Windows App I can see some traffic going through our firewalls between the app and the PE as well as a few FQND's like windows365.microsoft.com, xxx.rdweb-g-us-r0-wvd.microsoft.com, xxx.afdfp-rdgateway-r0.wvd.microsoft.com etc... It's all 443 traffic though, no 3389 or 3390. Entra logs show successful auth to Windows App and Conditional Access Policy result is Success with Grant Controls Satisfied and Session Controls Enforced. I have the Windows App version 2.0.918.0 with Client version 1.2.6876.0 which should be the latest at the time of this writing. I tried the old deprecated RemoteDesktop app and it does the same thing. One other thing I tried was downloading the. rdpw file from the web client and adding a bunch of parameters to the RDP advanced config like gatewayusagemethod, gatewaybrokeringtype, wvd endpoint pool etc. as they don't seem to be in there by default but it had no effect. I suspect those properties should be dynamically added at runtime rather than baked in to the config. Any help would be appreciated. Thanks.Improper 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
macOS: SSO no longer fully functional on AVD (Win11 25H2)
Hello everyone, Since updating our Test Azure Virtual Desktop Session Hosts from Windows 11 23h2 to 25H2 (26200.7462) , we've been experiencing an SSO issue that exclusively affects macOS clients. Symptoms For macOS users (Windows App), the following issues occur: Example Teams Teams shows the user as "Unknown User" Chat and collaboration features fail to load Error message: "You need to sign in again. This may be a requirement from your IT department or Teams, or the result of a password update. - Sign in" After clicking "Sign in," only a window appears with "Continue with sign-in" (no PW/MFA prompt) After this, all other applications work without further authentication Technical Details macOS Device: AppleM4 Pro macOS Tahoe 26.2 Installed WindowsApp version: 11.3.2 (2848) dsregcmd /status: No errors detected PRT is active and was updated for sign-in Entra Sign-In Logs: Error code: 9002341 EventLog on Session Host (AAD-Operational): Event ID: 1098 Error: 0xCAA2000C The request requires user interaction. Code: interaction_required Description: AADSTS9002341: User is required to permit SSO. Event ID: 1097 Error: 0xCAA90056 Renew token by the primary refresh token failed. Logged at RefreshTokenRequest.cpp, line: 148, method: RefreshTokenRequest::AcquireToken. Observations Affects: Both managed (internal) and unmanaged (external) macOS devices Does NOT affect: Windows clients connecting via Windows App Interesting: If a macOS user starts the session (with the error) and then reconnects on a Windows device, authentication works automatically there Workaround The issue can be resolved for macOS clients by removing the "DE" flag from "Automatic app sign-in" in the following file: C:\Windows\System32\IntegratedServicesRegionPolicySet.json Questions Is this a known issue? Has anyone experienced similar issues with macOS clients after the 25H2 update? Why does this issue only occur with macOS clients? Why does SSO only work after removing the "DE" flag for macOS devices, and why are Windows devices not affected? I would appreciate any insights or confirmation of this issue! Thank you and greetings FT_1
Single-Sign On
After troubleshooting an issue for a customer, we determined that the prerequisites for enabling SSO at the AVD host pool level is not strictly enforced when a user goes to execute the SSO workflow from MSRDC or the Windows App. Meaning, that if an administrator does not enable the -IsRemoteDesktopEnabled flag on the Service Principals "Microsoft Remote Desktop" and "Windows Cloud Login" respectively. Setup: Deploy Entra ID Joined session hosts to a host pool and enable the "Microsoft Entra single sign-on" RDP property to "Connections will use Microsoft Entra authentication to provide single sign-on" or update the RDP connection string with 'enablerdsaadauth:i:1'. Result: User will not receive the 'Windows Security' dialog box to access the session host with their Entra ID credentials. Caveat: Be aware that to sign in with Entra ID credentials, minimally, the host pool RDP settings must contain 'targetisaddjoined:i:1'. Microsoft states this is going away and blending into 'enablerdsaadauth:i:1', which also enables SSO. It seems a bit odd of a move in my opinion and having two separate RDP properties makes sense if a company does not want SSO. But it is in alignment with Microsoft's push for passwordless authentication. For the Microsoft AVD team, why does this behavior exist and is it on the roadmap to be fixed if it's a known gap?Azure’s Default Outbound Access Changes: Guidance for Azure Virtual Desktop Customers
After March 31, 2026, newly created Azure Virtual Networks (VNets) will no longer have default outbound internet access (DOA) enabled by default. Azure Virtual Desktop customers must configure outbound connectivity explicitly when setting up new VNets. This post explains what’s changing, who’s impacted, and the recommended actions, including Private Subnets. What is Default Outbound Access (DOA)? Default Outbound Access is Azure’s legacy behavior that allowed all resources in a virtual network to reach the public internet without configuring a specific internet egress path. This allowed telemetry, Windows activation, updates, and other service dependencies to reach external endpoints even when no explicit outbound connectivity method was configured. What’s changing? After March 31, 2026, as detailed in Azure’s communications, Azure will no longer enable DOA by default for new virtual networks. Instead, the VNet will be configured for Private Subnet option, allowing you to designate subnets without internet access for improved isolation and compliance. These changes encourage more intentional, secure network configurations while offering flexibility for different workload needs. Disabling Private Subnet option will allow administrators to restore DOA capabilities to the VNet, although Microsoft strongly recommends using NAT Gateway to provide outbound Internet access for session hosts. Impact on Azure Virtual Desktop Customers For Azure Virtual Desktop deployments created after March 31, 2026, outbound internet access must be explicitly configured, otherwise deployment and connectivity of the Session Hosts will fail. Existing VNets remain unaffected and will continue to use the configured internet access method. What You Should Do To prepare for Azure’s Default Outbound Access changes and ensure your Azure Virtual Desktop deployments remain secure and functional. Recommendations Update deployment plans to ensure either an explicit NAT, such as a NAT Gateway or Default Outbound access (not recommended) is enabled by disabling the Private Subnet option. Test connectivity to ensure all services dependent on outbound access continue to function as expected. Supported Outbound Access Methods To maintain connectivity, choose one of these supported methods: NAT Gateway (recommended) Note: Direct RDP Shortpath (UDP over STUN) cannot be established through a NAT Gateway because its symmetric NAT policy prevents direct UDP connectivity over public networks. Azure Standard Load Balancer Public IP address on a VM Azure Firewall or third-party Network Virtual Appliance (NVA). Note, it is not recommended to route RDP or other long-lived connections through Azure Firewall or any other network virtual appliance which allows for automatic scale-in. A direct method such as NAT Gateway should be used. More information about the pros and cons of each method can be found at Default Outbound Access. Resources: Azure updates | Microsoft Azure Default Outbound Access in Azure Transition to an explicit method of public connectivity| Microsoft Learn Quickstart: Create a NAT Gateway Quick FAQ Does this affect existing VNets? No. Only VNets created after March 31, 2026, are affected. Existing VNets will continue to operate as normal. What if I do nothing on a new VNet? Host pool deployment will fail, and connectivity will fail because the VNet does not have internet access. Configure NAT Gateway or another supported method before starting a host pool deployment. Why do Azure Virtual Desktop session hosts need outbound internet access? Many Azure Virtual Desktop functions depend on the session host having outbound access to Microsoft services. Without configuring NAT Gateway or another supported method of explicit outbound for the VNet, Azure Virtual Desktop will not deploy or function correctly. What are the required endpoints? Please see https://learn.microsoft.com/azure/virtual-desktop/required-fqdn-endpoint?tabs=azure for a list of the endpoints required. Why might peer-to-peer connectivity using STUN-based UDP hole punching not work when using NAT Gateway? NAT Gateway uses a type of network address translation that does not support cone symmetric NAT behavior. This can prevent STUN (Simple Traversal Underneath NAT) based UDP hole punching, commonly used for establishing peer-to-peer connections, from working as expected. If your application relies on reliable UDP connectivity between peers, STUN may revert to TURN (Traversal Using Relays around NAT) in some instances. TURN relays traffic between endpoints, ensuring consistent connectivity even when direct peer-to-peer paths are blocked. This helps maintain smooth real-time experiences for your users. What explicit outbound options support STUN? Azure Standard Load Balancer supports UDP over STUN. How do I configure Azure Firewall? For additional security you can configure Azure Firewall using these instructions: https://learn.microsoft.com/en-us/azure/firewall/protect-azure-virtual-desktop?context=/azure/virtual-desktop/context/context . It is strongly recommended that a direct method of access is used for RDP and other long-lived connections such as VPN or Secure Web Gateway tunnels. This is due to devices such as Azure firewall scaling in when load is low which can disrupt connectivity. Wrap-up Azure’s change reinforces intentional networking for better security. By planning explicit egress, Azure Virtual Desktop customers can stay compliant and keep session hosts reliably connected.
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?
Issues with FSLogix Profiles on Win11 25H2 Multiuser sessionhost's
Hey guys we have currently lot of issues with AVD and FSLogix 26.01. There seems to be an issue that the profile container isnt't unmounted correctly. We have lot's of users who are not able to login correctly because the profile can't be mounted because its already in use by another process. I'm currently looking what could cause that. We use a Azure files storage were i don't see any issues. It looks like a process within the userprofile is blocking the unload of the profile. Should i be able to see in the logs of FSLogix which process is causing this. Or what is a effective way to troubleshoot that? Thanks for any help Best regards Marc
AVD Remote published Application Disconnection
Is anyone aware of any known issues with AVD Remote Applications? We’re experiencing random disconnections across all Remote App users, with error details in insight point to StackCrash . The January 2026 update and OBB fix patches have already been applied, but the problem persists. ServiceRDStackStackCrash (-1073741819)
