Forum Widgets
Latest Discussions
Convert Azure Files Storage account to AES256
Hi, Mild panic attack, so storage accounts used for Azure files were oriignally set up without AES256, looks like the hybrid join script now defaults to AES256. Which is great. So following this guide: Use Azure Active Directory Domain Services (Azure AD DS) to authorize user access to Azure Files over SMB | Microsoft Learn Looks like the original storage accounts were set up with RC4, we need to convert our existing storage accounts from RC4 to AES256. As a test, I created a new storage account on RC4, ran the PowerShell command to convert to AES256. Looks like it worked fine. Did this on the production AVD storage account. Lost access to the share, my heart sank. I can see KerberosEncryptionType was originally empty: Get-AdComputer avdprofilestorage -KerberosEncryptionType ran the command Set-AdComputer avdprofilestorage -KerberosEncryptionType AES256 few moments later, lost access. To revert there was no way to set a null command so ran: Set-AdComputer avdprofilestorage -KerberosEncryptionType RC4 then everything came back. Maximum compatibility is set on the storage account. Just wondering if there is anything else I have missed? Worst case scenario is being locked out of the share. Thanks
RD Client fails to connect if Screen Capture Protection enabled
Hi there, I have tested this by disabling the reg key (fEnableScreenCaptureProtect) that the policy applies, and I can then connect via my Android app. Is this something that will be addressed as my organization enables Screen Capture Protection but it prevents me from using my Android phone.H.264/AVC 444 mode on non-GPU enabled series in Azure Virtual Desktop
Hi, does enabling H.264/AVC 444 mode on non-GPU enabled (N series) VMs makes any sense in an Azure Virtual Desktop environment? Will it leverage the internal video card for encoding or it needs a dedicated GPU like in "N" series? Thanks a lot. AndreaWindowsAppRuntime 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 ArchitectUnable to logon using Dell WYSE terminals
Hi all, I'm having an issue logging into AVD from Dell WYSE terminals. I have created a dynamic host group and added a service principal for them per guidance from Microsoft, and that has fixed an issue where the permission granting pop up was not displaying. After that, logon works fine with the web client but it will not complete sign-on with the Dell WYSE client. I have found the following errors in Azure AD but at a loss how to resolve as I have already added a service principal to the dynamic groups for hosts and unable to add a service principal for Windows Virtual Desktop AME.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
Azure Virtual Desktop (Pooled) – Sessions ending unexpectedly and users stuck across session hosts
Hi, We are currently investigating an issue in an Azure Virtual Desktop (AVD) environment where users are intermittently disconnected during sign-in or are unable to reconnect to their sessions. Environment: Azure Virtual Desktop Host pool: Pooled OS: Windows 10 / Windows 11 Enterprise multi-session FSLogix enabled Client: Windows App (Remote Desktop) Error message seen by users: "Your Remote Desktop Services session has ended. The administrator has ended the session, an error occurred while the connection was being established, or a network problem occurred." What we are seeing: Users fail to connect or get disconnected shortly after login. Session hosts appear healthy and powered on. No admin-initiated logoff is taking place. Rebooting the affected session host sometimes resolves the issue, but only temporarily. Actions already taken: Restarted AVD agent services on the session hosts. Placed affected hosts in drain mode. Rebooted the VMs. What we suspect: Some users may still have active or disconnected sessions on previous session hosts, possibly combined with FSLogix profile locks, which could be preventing new sessions from starting correctly. Questions: What is the recommended way to identify which users are logged into which session hosts across a pooled host pool? Are there best practices using the Azure Portal or PowerShell to detect and clean up stuck or disconnected sessions? Has anyone seen similar behavior in pooled AVD environments with Windows 10/11 and FSLogix enabled? Any advice or pointers would be appreciated. Thanks.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.
