(Solved) Investigating issue with Windows 10 Enterprise (multi-session), version 2004


Microsoft has recently released Windows 10 Enterprise (multi-session), version 2004, also known as the Windows 10 May 2020 Update.


Three images are offered to Windows Virtual Desktops customers and can be found in the Azure gallery as follows:  

  • Windows 10 Enterprise, Version 2004 
  • Windows 10 Enterprise multi-session, Version 2004 
  • Windows 10 Enterprise multi-session, Version 2004 + Office 365 ProPlus 

We are investigating an issue where newly deployed or upgraded VMs can no longer be accessed through Windows Virtual Desktop. While we are investigating, it's recommended to use the previous of the image versions available which includes version 1809, 1903 or (recommended) 1909. 

Any updates will be shared in this thread.


Update 7/17/2020: 
The fix has been deployed and Windows 10 (multi-session), version 2004 is now fully supported on WVD. 


Update 6/29/2020: 
We've identified an issue in our deployment, a fix is currently being scheduled and it's expected to be rolled-out mid-July. 


Update 6/2/2020: 
It's possible to work around the issue by adding the following registry key, followed by a reboot: 








Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\rdp-sxs]







34 Replies

Hi Pieter, 


I noticed this a few days ago when deploying an image based on 20H1, the issue is that the SXS component will not automatically be installed during deployment.


So I did some more testing today, my conclusion so far.


Deploying a WVD host based on 20H1 will fail to install the Remote Desktop Services SxS Network Stack component. Initial the host will be Unavailable in the hostpool. After some minutes the host will get the status Upgrading. Initial only two components will be installed (Remote Desktop Agent Boot Loader and the Remote Desktop Services Infrastructure Agent). After upgrading the Geneva Agent will be installed, but still the status of the machine is Unavailable.


If you check your remoting connection with qwinsta you will not see the SXS component, this component is needed for the reseverse connectivity. In the folder C:\DeployAgent you will find a folder RDInfraSxsStackInstall with a single .MSI file, you can install this manually. You will find version 1811. After installing the machine will once again go to the upgrading status. This time a newer version of the SXS stack will be installed but the status will eventually be Upgrade failed.  The result is two versions of the SXS agent are installed. the 1811 and 2003 version. I think this has something to do with the fact that the installer is unable to remove the agent.


You can manually remove the older version and reboot the host (Watch out, the uninstall will stop the Remote Desktop services).After the reboot the host should be available and you can now login.


Do you have any ETA for a fix? If you need some testers let me know!

I managed to upgrade our infrastructure, but my customers and my lab could replicate a service hang of Termserv during the install process at 76%. (which cause obviously an outage for these specific servers). Our internal server is running 2004 but I got a RDPBASE.DLL crash a few minutes ago. Could it be related to agent upgrades on your side? I dont really feel that 2004 is reliable to be used as a mutli-session service.


Nom de l’application défaillante : svchost.exe_TermService, version : 10.0.19041.1, horodatage : 0x7f0c4c00
Nom du module défaillant : RDPBASE.dll, version : 10.0.19041.84, horodatage : 0x5ef881e2
Code d’exception : 0xc0000005
Décalage du défaut : 0x0000000000048c3b
ID processus défaillant : 0x4f0
Heure de démarrage de l’application défaillante : 0x01d6380454ce2de9
Chemin de l’application défaillante : C:\WINDOWS\System32\svchost.exe
Chemin du module défaillant : C:\WINDOWS\system32\RDPBASE.dll
Code de rapport : f5e255e4-c58d-4bd8-afee-9caa45e4bbc9
Nom complet de l’ensemble défaillant :
ID de l’application relative à l’ensemble défaillant :

@SDingemanse thanks for your reply (and WVD Community podcasts :smile:)


The sxs stack install is not needed for reverse connect on the 2004 version of Windows, the rdp-sxs reg key enables that. However - that behavior will also change soon where the SxS stack will be installed on 20H1 also. We recommend not to manually install or uninstall stack components.

Until we fix the issue described above we recommend to install the 1909 version of Windows 10 Enterprise multi-session. I'm not sure if this issue is related, please let us know once we resolve this issue and we can take a look - it will require more debug/log information and probably a CSS case. Thanks!
Just a confirmation that this works for our environment.

Deployed new pool with 2004 and experienced this issue on Tue where users could not access.

Applied this registry key and rebooted all hosts, we are now good to go concerning access using Remote Desktop app.

Windows 10 Enterprise multi-session, formerly known as Windows 10 Enterprise for Virtual Desktops (EVD), is a new Remote Desktop Session Host that allows multiple concurrent interactive sessions. Previously, only Windows Server could do this. This capability gives users a familiar Windows 10 experience while IT can benefit from the cost advantages of multi-session and use existing per-user Windows licensing instead of RDS Client Access Licenses (CALs). For more information about licenses and pricing, see Windows Virtual Desktop pricing.

@Pieter Wigleven (WINDOWS) 


Hi Pieter,


Do you got some more information about the versions which should get installed on the 20H1 image version? and which agent are we talking about?


I can see the Configuration.zip file has been updated with a newer version of the Remote Desktop Services Infrastructure Agent. This is 1.0.1932.4800, after deployment via the gallery (Spring release), there is a newer version 1.0.1932.6700 being installed during the Upgrading status (the other version still remains installed after installation).


And the same issue still exist, after a reboot the host become Available again in the portal but the same error occured when connecting.

Error code: 0x3000047


What can I check to make sure the fix Microsoft has provided in the new WVD agent has been applied?


With kind regards,


Stefan Dingemanse


@Pieter Wigleven 


How can we update our Golden Image of v2004 with the new agents?


Links here still download the Microsoft.RDInfra.RDAgent.Installer-x64-1.0.1932.4800.msi instead of the new WVD agent.


Applying the registry seems to be the only way for our newly deployed Session Hosts from our v2004 golden image to function.

@limaecho The agent will update itself after deployment. Let me check with the team responsible for the agent whether there are any plans on updating the agent available for download.  

@Pieter Wigleven (WINDOWS) 


Hi Pieter - unfortunately that is not the case. When I deploy our golden image - we cannot connect to the Session Host - till we apply the registry key.


Once registry key is applied. We can connect. How do I check if the agent has "updated" ?

@limaecho You can see the version number by looking in add/remove software. I'm discussing this issue internally and will share more info as soon as available. 

@Pieter Wigleven (WINDOWS) 

Thanks, we built new pool with 2004 today and had the same issue, we put in the reg value and we can connect now but when we go to programs and features we do not see the SxS Network Stack at all.  I have attached a pic.  Will wait to hear back.  





@Pieter Wigleven (WINDOWS) 

Hi Pieter,


Any update on this issue?


With kind regards,


Stefan Dingemanse

@SDingemanse we're discussing this internally, will get back to you asap. 

I finally gave up on 2004 and rolled back to 1909. Its obviously not ready to be used in WVD with all the workarounds and issues.  I even started having an issue where my 2004 boxes lost their licenses and could not reach the license server.   Hopefully in a month or two they will have the issues worked out and a better upgrade path.

We've updated the agent which is deployed using ARM but identified an issue which leads to the same behavior. We're working on it, apologies for the delay!
Totally agree with you as I am on the same boat. 2004 is not ready at this point as I am told by WVD Blackbelt Engineers to wait for fix.

@Pieter Wigleven (WINDOWS) There was an OneDrive files on-demand issue with 2004, do you know if it was fixed?

The issue was that all OneDrive files were downloaded automatically, they were supposed to only download when the user opens the file.