Introduction
Most Windows Virtual Desktop customers know that there is a list of URLs that are very important to WVD. What some people don’t know is that if the WVD session hosts (so all WVD VMs) cannot reach these URLs, the result is that the WVD deployment is in an unsupported state.
The complete list of required URLs that the WVD Session Hosts need to reach is listed here: Windows Virtual Desktop Required URL list - Azure | Microsoft Docs
Problems when required URLs cannot be reached
Even if you, for whatever reason, are not keen on making sure the URL list is reachable for all Session Hosts, you really should because it negatively impacts the quality of the WVD service and could lead to higher costs. Here are some problems you might run into because the session hosts cannot communicate with the URLs on the list:
- The session host cannot communicate its status to the WVD control plane. Your users may be redirected to a server that is offline, unhealthy or otherwise a bad choice for a user connection. Obviously, this will result in a bad user experience.
- Adding hosts to a host pool either via the WVD blade in the Azure Portal, via a script or even via autoscaling might fail or may provision the wrong amount of VMs. This could be too little VM but also (way) too much VMs leading to a bad user experience or unexpected high costs.
- The WVD blade in the Azure Portal may show the wrong status from the WVD agent giving you inaccurate or incomplete data to base your management operations and support decisions. This impacts the quality of the WVD services provided to your end users or customers.
- You may not have the latest version of the WVD agent(s): The agents are auto-updating and require to know which versions are installed or that there is a new version available. This check and update won’t be possible, if the session host cannot communicate this information to the WVD control plane.
These are just some examples. There could also be other unexpected results. In fact, many -if not all- future WVD features will depend on accurate information about your deployment so access to the RequiredURL list is critical.
Unfortunately, it’s not always easy to tell if (one or more of ) the required URLs are blocked because users are successfully connecting. As you can tell from the example problems, the fact that users can successfully connect to their session does not mean that there are not problems looming – also with the supported state of your WVD deployment.
Making sure the required URLs can be reached
So, to be proactive, it’s important to make sure that communication from the session hosts to the required URL list can flow. Since almost all ports the WVD agents uses to communicate with the control plane are web ports, be sure to exclude the traffic from any kind of proxy inspection/interception as well, in additional to firewalls, NVAs and other usual suspects. A good example on how to configure a firewall with Windows Virtual Desktop can be found here: Use Azure Firewall to protect Windows Virtual Desktop | Microsoft Docs. In this article Azure Firewall is used, but the same design pattern is also applicable to other Firewalls.
Once you have made sure the required URLs are reachable from the session hosts you should check it, just to make sure it works. One quick and easy way to verify if the WVD agents can reach the required URLs is by checking the event log for source “WVD-Agent” on a representative session host (use a production session host, not a test session host). When all is well, you will only see Event ID 3701 like the example below:
When something is wrong you will see warnings with Event ID 3702 or errors with event ID 3703 showing which URLs cannot be reached.
Another option for customers using the ARM release, is to check Azure Advisor (which is always a good idea). In case there the WVD agents cannot reach the required URLs, you will see this message under the Operational Excellence section: “Not enough links are unblocked to successfully implement your VM”
In the future you can expect more help from us in making it easier to see when the required URLs cannot be reached, but it will always be a best practice to make sure the required URLs are reachable from the session hosts right from the very start of your Windows Virtual Desktop deployment.