Forum Discussion
Consistent Thin Client Disconnection from WVD Pool
Sbarnet Hi, we are also experiencing these issues for two weeks now (50 user environment).
- Happens from multiple locations (so independent of network or ISP).
- Happens on both Windows 10 and HTML5 clients.
- Seems to happen completely random.
- Problem so far not related to a particular WVD host in the pool.
- Some days no problems at all, the next day it could me 80+ disconnects on one day.
- It seems to be related to a session. When user A gets is in the morning, chances are high he will get it multiple time a day, until he completely logs off and on again, so a completely new sessions is build up.
Already have a Microsoft case running for this, but so far no solution, or not even a cause. I suspect Azure's WVD gateway, but can't prove this yet.
Does anyone else experience this in the West Europe region?
Greets, Marco
Marco Brouwer we have the same problem at a client environment. It is really unworkable and we have a support case running for a few weeks still not resolved, sending in network traces almost every day but no real solution yet.
In my LAB I was able to reproduce it when we use the Azure NAT Gateway on the WVD subnet, removing the NAT gateway fixed the issue in my LAB, but for the client it did not fix the issue.
This client environment is running on WVD Classic (Fall release), next week I am going to migrate it to WVD Spring Release in the hope it will work more stable.
It is not really a WVD issue in general, we have clients that have no issues at all.
The issue is also Disconnect and auto-reconnect, it takes about 10-30 seconds each reconnect. Customer is using USB based smartcards for some authentication in an application. In every reconnect the application crashes because the smartcards is unreachable for all that time.
Region: West Europe.
Do you use an Azure NAT Gateway on the WVD subnet?
- Hi Stefan,
One of customers complained yesterday about several disconnects / reconnects. Reporting users where not on same WVD host, some working from home, some from 4G, some from the office. The only common component in that situation is the WVD gateway service, managed by Azure.
They use WVD classic in combination with a standard load balancer (for the purpose of having a static outgoing public ip), not Azure NAT gateway (load balancer is cheaper).
We have another customer on WVDv2, also with same load balancer configuration, no problems reported.
So I guess that if there is a connection between our issues, is has something to do with NATting the traffic on classic WVD, not with the new NAT GW product in particular.
To be honest, I still believe in the (unproved) theory that Azure WVD has 1001 gateway / broker servers, and it just depends on the fact if your Azure tenant gets assigned to a buggy one or something like that. Or that some WVD gw has some problems for an x period of time, or gets overloaded and customers are fe assigned to a different gateway cluster by hand of some non instant process.
In the history of this post, multiple people complain about "waves of disconnects" in the same period of time in the same Azure region, but not all of them at once. That would strengthen this theory.
But no way Microsoft would ever admit to something like that :). For us, I find the flow of traffic / WVD sessions within the by Azure managed part of WVD (brokering / gateway) a big unknown foggy cloud. You don't get enough information from the configurable logging to pinpoint / prove that something goes wrong in there and on what server in their big cluster.
When you contact MS support, your case goes from team to team, and they always point the finger to anything but themselves, although I provide "proof" that the problem is not on our side. If it's not on my side, on whose side is it then?
Also, they disabled reading WVD logging with powershell permanently around April due to "performance problems", that was actually confirmed by MS to me. Sure, you can now read the same logs with log analytics in Azure, but the reason provided for disabling these Powershell command remains "performance problems". Hmmm...
Please post your MS case number here, so Microsoft can bundle multiple cases into one big issue they can't ignore.
GreetsMarco Brouwer thank you for your reply.
In my LAB WVDv2 also gave the issue with an Azure NAT Gateway. I have a small scale lab, with a D2s_v3, if I put the Azure NAT Gateway in the network, open de WVD desktop, start youtube with some nice long fireplace video, it doesn't take more than 5-10 minutes before the first reconnect occurs. I even filmed it with OBS Studio and already wrote a concept blog for my website, something is really off in WVD with the NAT Gateway I believe.
Before NAT Gateway existed I sometimes create an Ubuntu based NAT machine running on B1s (https://www.microcloud.nl/azure-nat-with-ubuntu-linux/)
I also tried that in my LAB and it seems that the reconnects did not occur. We also have one client running in WVD_v2 with an Azure Express Route, and they routed the internet back over the express route via their local ISP, they have no issues with reconnections.
Our client with the issues currently runs on WVD Classic, without any NAT/Load balancers or whatever, just the default internet breakout and the issues still occur.
I am currently still on holiday leave, next week I will discuss if I can publish the ticket number. We also are going to start creating new host pools in WVDv2 asap.
@ everyone.
I want to let everybody know, we have resolved the issue. That is, removing the Azure NAT Gateway from our WVD servers removed the reconnection problems.
At first we did not think it was resolved because after removing Azure NAT Gateway one of the two customer sites using WVD still had the same issues. Unfortunately due to holidays it took some time to learn that one site was resolved and the other wasn't.
After the holidays we confirmed that the issue was also resolved if we connected to WVD from home locations.
On the other site where the reconnect issue did not resolve we finally discovered that our Fortigate 51E firewall is causing the same symptoms as the Azure NAT gateway, thus confusing us in the real root case of the issue.
In the Fortigate firewall we disable all HTTPS inspection/proxy etc. But that did not resolve the problem.
The support ticket at Fortinet is still open to resolve the issue on that site. We have bypassed the Fortigate for the WVD clients with a Draytak firewall/NAT device, all those clients have no issues anymore with WVD reconnection problems.
About the Azure NAT Gateway causing WVD reconnection problems;
Microsoft confirmed in the support ticket:
"It appears this is a bug with NAT gateways and WVD. It is currently being worked on for a resolution with no current ETA on a fix."
Hope this information helps anyone else.