Forum Widgets
Latest Discussions
Azure Virtual Desktop - Black Screens on logins - What we've tried so far
TLDR - Azure Virtual Desktop Black Screens. Could be 2 Min long, could be much longer. Tried removing stuck profiles, spun up all new VMs to see if that would fix it, finally disabled an application service that was polluting the Event logs constantly with appcrashes. Hoping that maybe the event logs weren't able to keep up so we had a black screen while events caught up. Grasping at straws. We started getting reports of black screens when users login to one of our AVD Host Pools. Our users are using FSLogix for profiles, but we've also seen the issue when logging via RDP with a local admin account. We tested and saw similar results where you login, FSLogix Prompt goes by, then to Preparing Windows, then black screen. In a normal login, this black screen will last 10-20 seconds before desktop comes available and user can begin their session. With this issue, we were seeing black screens that just stayed there until you forced a logout of your account. We saw some profile issues with the VMs in the pool appearing to be stuck on a VM when it should be removed upon logoff with FSLogix and we saw some stuck local_username FSLogix profiles still in the users folder. Instead of finding the needle in a haystack, we spun up a new group of VMs and put the others in drain mode / excluded. With the new VMs, logins from RD Client were working fine yesterday afternoon, evening and this AM. But later in the morning, we saw some issues with users getting a black screen lasting 90 sec - 2 min before desktop loaded in. I had it happen to me when logging in, but it seemed to go away once I tried a couple more times. I even directly RDPd into the host that I had the 2 min black screen for me and was able to get in quickly. So issue appears to still be showing, but not as bad. We looked in event logs and saw that one particular application - the Aspen Multicase Web service was polluting the service event logs with appcrash errors every few seconds. So we've disabled that application service on all the VMs in the pool and logins have been normal since. We read event logs that were event 4625 (failed login) but the event said event logs couldn't keep up and needed to stop duplicate events...so we were thinking that this service was constantly writing to event logs, could the slow logins happen when the service is trying to run, failing and writing to event logs. the logs wouldn't be able to write the login info. But every other change we made things seem fine afterward for a while, but then the black screen will come back for at least 90sec - 2 min. Any suggestions on things we can try / look at that could be causing this?
MSIX app attach Azure portal integration public preview
MSIX app attach is an application layering solution that allows you to dynamically attach an application (that is an MSIX package) to a user session. Separating the application from the operating system makes it easier to create a golden virtual machine image, and you get more control with providing the right application for the right user. Previously, you had to use PowerShell scripts to enable MSIX app attach. MSIX app attach capability is now available in public preview in the Azure portal and is integrated with Azure Resource Manager. This eliminates the need for custom scripts and makes it possible to publish your packaged applications to application groups with a few clicks. Draft troubleshooting guide for MSIX app attach is available here. Overview and requirements Before you get started, make sure to fill out and submit this form to enable MSIX app attach in your subscription. If you don't have an approved request, MSIX app attach won't work. Approval of requests can take up to 24 hours during business days. You'll get an email when your request has been accepted and completed. The following are the requirements to setup MSIX app attach in a Windows Virtual Desktop environment: Host pool in Windows Virtual Desktop with at least one active session host Host pool in the validation environment MSIX packaged application expanded into an MSIX image MSIX image is uploaded to file share The file share is accessible for all session hosts in the host pool When using a digital certificate that is not sourced from a CA please follow instructions here on each VM in the host pool This video walks through the MSIX app attach UI. Deploy WVD (Windows Virtual Desktop) host pool The steps for deploying a WVD host pool are outlined here. It is mandatory to provision the session host pool in the validation environment. MSIX application MSIX app attach requires an application packaged as MSIX. If you do not have an MSIX application you can use the MSIX Packaging tool to repackage a Win32 application to MISX application. Instructions are available here. Prepare MSIX image MSIX app attach needs MSIX application to be stored in a VHD(x). Steps on how to perform the expansion are available here. If you do not have access to an MSIX application and MSIX images feel free to use these. They are provided without any guarantees and should not be used in production environments: Application name URL Chrome as MSIX image https://1drv.ms/u/s!Amut9BnVnw7mkOVMWy-sU8aiaStuxQ?e=AqwZ0D Chrome in an MSIX package https://1drv.ms/u/s!Amut9BnVnw7mkOVLPExhghP4iM8LRQ?e=wJHd9P Microsoft Edge Dev v89 as MSIX image https://1drv.ms/u/s!Amut9BnVnw7mkOVddlHiIoei4RdROQ?e=kwdvDq Microsoft Edge Dev v89 as MSIX package https://1drv.ms/u/s!Amut9BnVnw7mkOVczWWmEiUhv2IC3A?e=eBGL8B Microsoft Edge Dev v87 as MSIX image https://1drv.ms/u/s!Amut9BnVnw7mkOVbdz4gmTb7rqHoeg?e=6dEhj5 Microsoft Edge Dev v87 as MSIX image https://1drv.ms/u/s!Amut9BnVnw7mkOVaArIPkiAg5XzusQ?e=ZthNbz PowerBI as MSIX image https://1drv.ms/u/s!Amut9BnVnw7mkOVkUdswoKXTk9dfUw?e=fGTHy5 Note: this has dependencies that need to be delivered in the master image Links available here https://1drv.ms/u/s!Amut9BnVnw7mkOQth1hkT-SRdP2__g?e=YHbice PowerBI as MSIX package https://1drv.ms/u/s!Amut9BnVnw7mkOVi5SXqDxAr6MBAKw?e=pm1c2q WVDMigration as MSIX image (test different cert type) https://1drv.ms/u/s!Amut9BnVnw7mkOIEPLX6PYOzx96nrg?e=9qEpJc WVDMigrationBAD as MSIX image (bad packaging format) https://1drv.ms/u/s!Amut9BnVnw7mkOF6izJaA6rMxih_fQ?e=VU6Wbp Microsoft Edge Dev v87 as MSIX image (expired cert) https://1drv.ms/u/s!Amut9BnVnw7mkOJamDr-mrs3rOoeCg?e=43JT7E Notepad++ as MSIX image (missing cert test) https://1drv.ms/u/s!Amut9BnVnw7mkOF-o-E-bhp_btLgJw?e=6DO9ea If you are using your own application, you will need to install the certificate used to sign the MSIX package. Install certificates If you are using the provided MSIX applications, there are two certs: For Chome, Edge, and Power Bi: WVDContosoAppAttach. For WVDMigration*, WVDMigrationFabrikam Configure a file share All session hosts need access to the file share with MSIX app attach packages. This Tech Community blog covers the process. Configure MSIX app attach via Azure portal Open a browser, preferably in incognito mode, and load the following link: https://preview.portal.azure.com/?feature.msixapplications=true#home In the search bar type Windows Virtual Desktop and click on the service. Select a host pool where MSIX applications are to be delivered. Select MSIX packages. This will open the data grid with all MSIX packages currently added to the host pool. Click + Add. This will open the Add MSIX package blade. MSIX image path – this is UNC path pointing to the MSIX image on the file share. For example, \\storageaccount.file.core.windows.net\msixshare\appfolder\MSIXimage.vhd. MSIX package – if a valid, resolvable, and accessible path is provided this drop-down will be populated by all the MSIX packages in the MSIX image. Package applications – list of MSIX applications available in an MSIX package. Display name – Optional display name to be presented in the interface. Version – MSIX package version automatically delivered from parsing the package. Registration type On-demand – this is the recommended type of registration. It postpones the full registration of the MSIX application until and the user starts the application. Log on blocking – this type of registration is executing during session logon hence adding time to session logon completion. State – MSIX package has two states (Active and Inactive). When a package is active users can interact with it. Inactive packages are ignored by WVD and not delivered to users. Click Save. Publish MSIX application to an application group In the WVD resource provider navigate to the Application groups blade. Select an application group. Note: During MSIX app attach preview MSIX app attach remote apps may disappear from the user feed. The remote MSIX apps can disappear from the user feed because host pools in the evaluation environment may get served by an RD Broker in a production environment (this happens when the RD broker optimizes to improve the end-user experience). Because the RD Broker in the production environment doesn't understand the date of the MSIX app attach remote apps, it won't display them. Select the Applications blade. The Applications grid will display all currently added applications. Click + Add to open the Add application blade. Application source For desktop app groups the only source for applications is an MSIX package. For remote app group, there are three sources of applications. Start menu App path MSIX package MSIX package – display list of packages added to the host pool. Display name – Optional display name to be presented in the Applications interface. Description – Short description. Note the options below are only applicable to remote application groups. Icon path Icon index Show in web feed Click Save. Assign users to app group Select app group. Select Assignments To assign individual users or user groups to the app group, select +Add Azure AD users or user groups. Select the users you want to have access to the apps. You can select single or multiple users and user groups. Select Save. It will take five minutes before the user can access the application. Change MSIX package state Via the Applications grid Select MSIX packages. This will open the data grid with all MSIX packages currently added to the host pool. Select one or multiple that need to have their state change and click the Change state button. Via update package Select MSIX packages. This will open the data grid with all MSIX packages currently added to the host pool. Click on Package name in the MSIX packages grid this will open the blade to update the package. Toggle the State via the Inactive/Active button as desired and click Save. Change MSIX package registration type Select MSIX packages. This will open the data grid with all MSIX packages currently added to the host pool. Click on Package name in the MSIX packages grid this will open the blade to update the package. Toggle the Registration type via the On-demand/Log on blocking button as desired and click Save. Remove MSIX package Select MSIX packages. This will open the data grid with all MSIX packages currently added to the host pool. Select one or multiple that need to be removed click the Remove button. Removing MSIX application Navigate to the host pool and select Application groups. Select the application group from which the MSIX application is to be removed. From the application group blade select Applications. Select the desired application and click Remove.
Anyone experiencing session hosts becoming unavailable at random
Since the end of last week we have had three occasions where one of the session hosts randomly becomes unavailable. This happened in two separate AVD environments. Users get kicked out of their session and cannot reconnect. The user sessions are still marked as Active/Disconnected according to the Azure portal. We cannot RDP to the session host through the internal network. After we shutdown and reboot the session host, everything will work fine again. We noticed the following notable things: There are no event logs generated at all, starting 30-60 min prior to the 'crash'. Since the 28th of October Event Viewer is getting spammed by the following warning: Microsoft.RDInfra.RDAgent.Service.AgentUpdateStateImpl Unexpected last recorded state The "Remote Desktop Services Infrastructure Agent" has been updated on the 25th of October, to version 1.0.5555.1008 The "Remote Desktop Services SxS Network Stack" has been updated on the 31st of October, to version 1.0.2208.17300 This is also the first day that we experienced the problem. I have yet to find anything on this problem. Is anyone else experiencing this with their AVD environments?
File Explorer is slow when traversing files synced with OneDrive
Hello team, I have this customer who have this AVD deployment in production, they are managing with Nerdio and they recently move their storages to Azure NetApp. Event with this very optimized environment they are facing one specific issue with the OneDrive synced folders. They created this video that explains the issue in details. They also opened a support ticket, but they didn't help with this issue. They are facing that for a while and they are asking for more assistance. If anyone could have any clue would be great! A video demonstrating the issue can be found here: https://rivier.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=203b5b74-07d9-4ec1-8da0-b02a015a0e18 (the demonstration starts at the 2m10s mark). Thank you!The FSLogix 2201 Public Preview is now available
FSLogix 2201 Public Preview Update 1 has been published to address the issue outlined below. Please read details here. FSLogix 2201 is now available in Public Preview. This public preview is not recommended for production workloads. Please leverage your standard Microsoft support channels to report issues with this public preview release. ISSUE IDENTIFIED IN THIS PUBLIC PREVIEW RELEASE: We discovered an issue with the 2201 public preview that is impacting customers with session hosts configured to allow users to have more than one Windows session per user per host. In those situations, only that user's first session to a host will connect. Additional connections for that user to that host will fail to login. Your environment is impacted by this bug if you have the "Restrict Remote Desktop Services users to a single Remote Desktop Services Session" group policy set to disabled or the HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services\fSingleSessionPerUser regkey value is set to 0. We recommend impacted customers not install this public preview or revert back to the current generally available release. We are validating a fix for the issue and will publish an update to the public preview when it is available. Customers not impacted by this issue can continue validating this public preview release. Preview Details You can sign up here to participate in the Public Preview: https://aka.ms/fslogix/preview This release can be installed over all existing versions of FSLogix or you can perform a fresh install without a pre-existing FSLogix version. Here's what's new in this release: Fixed issue where the FSLogix Profile Service would crash if it was unable to communicate with the FSLogix Cloud Cache Service. The OfficeFileCache folder located at %LOCALAPPDATA%\Microsoft\Office\16.0\OfficeFileCache is now machine specific and encrypted so we now exclude it from FSLogix containers. Office files located outside this folder are not impacted by this update. Windows Server 2019 version 1809, and newer versions of Windows Server, natively support per-user search indexes and we recommend you leverage that native search index capability. FSLogix Search Indexing is no longer available on those versions of Windows Server. Windows 10 Enterprise Multi-session and Windows 11 Enterprise Multi-session natively support per-user search indexes and FSLogix Search Indexing is no longer available on those operating systems. FSLogix now correctly handles cases where the Windows Profile Service refCount registry value is set to an unexpected value. Over 30 accessibility related updates have been made to the FSLogix installer and App Rules Editor. A Windows event now records when a machine locks a container disk with a message that looks like "This machine '[HOSTNAME]' is using [USERNAME]'s (SID=[USER SID]) profile disk. VHD(x): [FILENAME]." Resolved an issue where the DeleteLocalProfileWhenVHDShouldApply registry setting was sometimes ignored. Fixed an issue where active user session settings where not retained if the FSLogix service was restarted. This was causing some logoffs to fail. FSLogix will no longer attempt to reattach a container disk when the user session is locked. Fixed an issue that caused the FSLogix service to crash when reattaching container disks. Fixed a Cloud Cache issue that caused IO failures if the session host's storage blocksize was smaller than a cloud provider's. For optimal performance, we recommend the session host disk hosting the CCD proxy directory has a physical block size greater than or equal to the CCD storage provider with the largest blocksize size. Fixed a Cloud Cache issue where a timed out read request (network outage, storage outage, etc.) was not handled properly and would eventually fail. Reduced the chance for a Cloud Cache container disk corruption if a provider is experiencing connection issues. Resolved an issue where temporary rule files were not deleted if rule compilation failed. Previously, the Application masking folder was only created for the user who ran the installer. With this update, the rules folder is created when the Rules editor is launched. Resolved an interoperability issue with large OneDrive file downloads that was causing some operations to fail. Fixed an issue where per-user and per-group settings did not apply if the Profile or ODFC container was not enabled for all users. Resolved an issue where the Office container session configuration was not cleaned up if a profile fails to load. Fixed an issue where HKCU App Masking rules leveraging wildcards would fail to apply. Fixed an issue where FSLogix did not properly handle logoff events if Profile or ODFC containers were disabled during the session or per-user/per-group filters were applied mid-session that excluded the user from the feature. Now FSLogix logoff related events will always occur if FSLogix loaded a container for the user. Fixed an issue that caused some sessions configured with an ODFC container to fail to login. Resolved an issue where the rule editor would crash if there were no assignments configured.[Announcement] Connectivity issues from synchronized users to VMs joined to AAD DS
Hi everyone, thanks for the continued testing of WVD. We’ve seen multiple connection errors with UPN when connecting to VMs joined to Azure AD Domain Services. We’ve done some preliminary investigations and figured out which scenarios are currently affected and which scenarios should continue to work. Works Logging into VM joined to Azure AD DS instance with Azure AD user sourced from Azure Active Directory (aka, New user created just in Azure AD). Does not work (and investigating fix) Logging into VM connected to Azure AD DS with Azure AD user sourced from Windows Server AD (aka, synchronized to Azure AD through Azure AD Connect). You will see an error in the Diagnostics similar to below: ErrorSource : RDBroker ErrorOperation : OrchestrateSessionHost ErrorCode : -2146233088 ErrorCodeSymbolic : ConnectionFailedUserSIDInformationMismatch ErrorMessage : OrchestrateAsync: SID value in the database is different than the value returned in the orchestration reply from the agent for user ≤user1@contoso.com≥ with Id 54a45a4c-41ad-4374-5e41-08d6e4d9acde. This scenario is not supported - we will not be able to redirect the user session. ErrorInternal : False ReportedBy : RDGateway Time : 7/16/2019 3:17:24 PM Workaround If your setup matches the description but you would still like to test, we suggest creating cloud users in Azure Active Directory for the time being. Resolution No current ETA, but working towards a fix. How to check where your user is sourced from You can navigate to the Azure AD portal or the Azure Active Directory blade in the Azure portal, then go to users:Announcing General Availability of FSLogix 2201 (2.9.8111.53415)
Today we are announcing the General Availability of FSLogix 2201. Updates include improvements to login and logoff times, cloud cache performance improvements, and 30+ accessibility updates. Download Location https://aka.ms/fslogix_download Installation notes This release can be installed over previous versions of FSLogix. Installation Instructions: Install FSLogix Agent - FSLogix | Microsoft Docs Changes • Fixed issue where the FSLogix Profile Service would crash if it was unable to communicate with the FSLogix Cloud Cache Service. • The OfficeFileCache folder located at %LOCALAPPDATA%\Microsoft\Office\16.0\OfficeFileCache is now machine specific and encrypted so we exclude it from FSLogix containers. Office files located outside this folder are not impacted by this update. • Windows Server 2019 version 1809, and newer versions of Windows Server, natively support per-user search indexes and we recommend you leverage that native search index capability. FSLogix Search Indexing is no longer available on those versions of Windows Server. • Windows 10 Enterprise Multi-session and Windows 11 Enterprise Multi-session natively support per-user search indexes and FSLogix Search Indexing is no longer available on those operating systems. • FSLogix now correctly handles cases where the Windows Profile Service refCount registry value is set to an unexpected value. • Over 30 accessibility related updates have been made to the FSLogix installer and App Rules Editor. • A Windows event now records when a machine locks a container disk with a message that looks like "This machine '[HOSTNAME]' is using [USERNAME]'s (SID=[USER SID]) profile disk. VHD(x): [FILENAME]." This event is generated from the METADATA file created in the user's profile directory. This file can be ignored, but not deleted. • Resolved an issue where the DeleteLocalProfileWhenVHDShouldApply registry setting was ignored in some cases. • Fixed an issue where active user session settings where not retained if the FSLogix service was restarted. This was causing some logoffs to fail. • Fixed an issue where FSLogix did not properly handle logoff events if Profile or ODFC containers were disabled during the session or per-user/per-group filters were applied mid-session that excluded the user from the feature. Now FSLogix logoff related events will always occur based off the FSLogix settings applied at login. • FSLogix will no longer attempt to reattach a container disk when the user session is locked. • Fixed an issue that caused the FSLogix service to crash when reattaching container disks. • Fixed a Cloud Cache issue that caused IO failures if the session host's storage block size was smaller than a cloud provider's block size. For optimal performance, we recommend the session host disk hosting the CCD proxy directory has a physical block size greater than or equal to the CCD storage provider with the largest block size. • Fixed a Cloud Cache issue where a timed out read request (network outage, storage outage, etc.) was not handled properly and would eventually fail. • Reduced the chance for a Cloud Cache container disk corruption if a provider is experiencing connection issues. • Resolved an issue where temporary rule files were not deleted if rule compilation failed. • Previously, the Application masking folder was only created for the user who ran the installer. With this update, the rules folder is created when the Rules editor is launched. • Resolved an interoperability issue with large OneDrive file downloads that was causing some operations to fail. • Fixed an issue where per-user and per-group settings did not apply if the Profile or ODFC container was not enabled for all users. • Resolved an issue where the Office container session configuration was not cleaned up if a profile fails to load. • Fixed an issue where HKCU App Masking rules leveraging wildcards would fail to apply. • Fixed an issue that caused some sessions configured with an ODFC container to fail to login. • Resolved an issue where the App Rules editor would crash if no assignments were configured. Resources FSLogix documentation: https://aka.ms/fslogix Download Location: https://aka.ms/fslogix_download
