We and third parties such as our customers, partners, and service providers use cookies and similar technologies ["cookies"] to provide and secure our Services, to understand and improve their performance, and to serve relevant ads [including job ads] on and off LinkedIn. For more information, see our Cookie Policy.
Select Accept cookies to consent to this use or Manage preferences to make your cookie choices. You can change your cookie choices and withdraw your consent in your settings at any time.
A few days ago, I got an email from a customer concerning that a lot of Azure Virtual Desktop [AVD] session hosts showing an error message from the internal health check:
SessionHost unhealthy SxSStack listener is not ready - Code -2147467259
Unfortunately, there was no failed event log from the WVDAgent in the application log. But the RemoteDesktopServices log shows some issues with the SxSStack as expected. Reinstalling the AVD agents doesn’t resolve the issue. But we found an easier way to bring the hosts back to life: Uninstalling the SxS Stack package and rebooting the host.
We used PowerShell to create a single-line script and Hydra to execute it on all affected session host:
Uninstall-Package -Name "Remote Desktop Services SxS Network Stack" -AllVersions -ForceThe short script can be deployed with #WVDAdmin, #Hydra, or any other solution having access to the hosts.
Please read the first and second articles in this blog series if you have not already.
WVD Connections Are TCP ONLY At the Moment. RDP Shortpath [UDP Support] Remains in Private Preview, And Adds Excess Costs To Your Deployment.
When WVD was originally architected, Microsoft chose to implement connections via a reverse proxy method. Basically, WVD clients connect to the distributed PaaS WVD Gateway service, which then pings the agent on a WVD host [the host in the hostpool selected by the WVD Broker PaaS role] to establish a reverse connection back to the client through the Gateway. As such, all connections are TCP only. For more mechanics on how this works, please read my earlier blog post on the topic.
Of course, TCP only RDP connections have a lot of drawbacks. For those of you as old, well, let’s say as seasoned as I am, you may remember the pre-RDP v8.0 days where all RDP connections were TCP only. Those days … those days sucked! TCP has built in congestion avoidance algorithms, so higher latency and lossier networks trigger those algorithms, which lead to “back off” or “timeout” intervals. When you’re trying to use RDP, that results in you clicking the mouse or typing something and then waiting a few seconds before you see that input post on the terminal server you’re working on. It’s frustrating.
Now, your Microsoft Azure sales rep will probably answer, “That’s why we have TONS of Azure regions around the world, so you can place your WVD hosts super close to your end users, so latency or lossy connections over TCP won’t be a problem.” However, if your company has multiple offices throughout a country, or even the world, this means you’ll be most likely be standing up more virtual machines, in more Azure regions, than you would if you just had a single high availability RDS infrastructure deployed that utilized a Remote Desktop Gateway. Why?!!
In classic RDS, you set up one or more Remote Desktop Gateway servers that receive incoming RDP connections from external users to your collections of terminal servers. Think of Remote Desktop Gateway as a highly optimized VPN specifically for RDS.
Back in Windows Server 2012 R2, Microsoft introduced dual transport for Version 8.0 of the RDP protocol, so it could now utilize both TCP AND UDP for sending/receiving data. This was a gamechanger, as now RDP could be leveraged for higher latency and lossy connections across continents- because UDP would overcome the poor connections and distance. Consequently, when Microsoft built the Remote Desktop Gateway server for Windows Server 2012 R2 and later operating systems, they designed it to route and marshal both TCP and UDP traffic to/from Remote Desktop Servers using ports 443 and 3391 respectively.
So, to sum it up, in classic RDS you theoretically could stand up one highly available RDS deployment in one region of the world, that could be used by RDP clients just about ANYWHERE in the world, with an acceptable user experience. All because of dual TCP/UDP transport, AND the ability of the Remote Desktop Gateway to handle and route both methods of transport.
Now, Microsoft realizes this current shortcoming in WVD, and so has created something called RDP Shortpath, which is currently in Public Preview. At its essence, RDP Shortpath is a way for the WVD client to see if there is a way for it to make a DIRECT connection to the WVD host, so that it can open up a side channel for UDP communications, improving the performance of the WVD experience.
Unfortunately, the only ways for this to work, more or less, is for you to establish either a separate VPN between the WVD client system and the Azure VNet containing the WVD host pools, OR to add a static IP to EACH AND EVERY WVD host that is publicly accessible on the Internet. Yikes!! Choosing EITHER of these options INCREASES total WVD costs, because you’re either paying for the Azure VPN OR you are paying for the static IPs. Do you see a trend? Microsoft will build a solution or workaround for you, but it will almost ALWAYS COST YOU MORE. Yet, they already have the technology in the classic RDS Gateway role to support both TCP/UDP. Thus, if you are an organization of any decent size, it makes MUCH more sense to continue to run Classic RDS, either in a private cloud/colocation facility OR in the public cloud like Azure, to reduce your infrastructure costs [fewer VMs total] AND reduce the need for VPNs or for static IPs.
Updates in WVD – Do You Feel Lucky, Punk?
In Part 2 of this blog series, I alluded to issues with updates when running Windows 10 multisession in Windows Virtual Desktop, as compared to running classic Remote Desktop Services with Long Term Servicing Channel [LTSC] versions of Windows Server. Let’s dive into that further.
Currently, there are two issues, as I see it, with updates in Windows Virtual Desktop.
The first issue is that at present you don’t have control over when Microsoft pushes updates to the WVD Infrastructure Agent and SxS Network Stack components on the Windows 10 multisession hosts you have running in your host pools. Why is this a big deal?
When Microsoft pushes these WVD agent updates to your session hosts each and every month, if the update fails to take place successfully, it can bring your hosts down completely, and you may have to either attempt to resolve the issue yourself on EACH host OR simply redeploy new hosts and reload applications. Neither of these is a desirable scenario, as it results in extra work for you and downtime for your users. See this thread for more gory details. I don’t know about you, but I don’t want to lose sleep every single month worrying about WVD agent stack updates getting botched.
Microsoft’s solution for this? The ever so euphemistically named validation host pool, of course. Basically, you designate one of your host pools as a validation host pool, and that host pool will be the guinea pig that gets the monthly updates first. If it goes down after these updates get pushed, only SOME of your users will be affected! That’s great right? You get to pay EXTRA compute costs in the form of additional VMs in an additional host pool to Microsoft in order to Q&A their WVD agent update process, and you still get to scramble when some of your users potentially go down. No thanks.
Another issue that has come up is how to best perform major updates to Windows 10 multisession. Some WVD customers ran into big problems last year when they did in place upgrades to Windows 10 Build 2004, as this broke the WVD agent/network stack components mentioned above and users could not connect. The affected organizations had to then scramble to reinstall the WVD network stack manually on all affected session hosts.
Bottom line, the WVD team at Microsoft is running so fast to introduce new features, they are working on the car’s engine while the car is in motion. This has caused issues in the past with both the forced push updates to the WVD infrastructure agent and network stack components that allow the WVD hosts to communicate with the WVD infrastructure and user clients, and 2.] has caused compatibility issues with in-place major updates to new Windows 10 builds.
Please continue on to my final post in this blog series, where I discuss another big issue with WVD, specifically Azure Active Directory and service reliability, and I recommend staying with Classic Remote Desktop Services for now.
Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.