Azure Virtual Desktop: Error: "Connection was refused because you tried to access a private endpoint resource without being connected to the private endpoint."

Question

I am setting up Azure Virtual Desktop. Host Pool Type is Pooled, Application Group has only one application - just the "Session Desktop". When I enable "Private Link" and "Disable Public Access" (AVD workspace: Global & feed, Host Pool: Connections) and then try to connect from a remote VM (in another VNET in Azure connected to this Session Host VNET over a VPN - please find the architecture diagram below), I get an error "Connection was refused because you tried to access a private endpoint resource without being connected to the private endpoint. Azure Virtual Desktop".

Connection topology:

Error:

I am using Remote Desktop Client for AVD. When I Subscribe using the user name, I get the session desktop downloaded to the client. So, I assume, this shows that the discovery is working. However, when I double click on the Session Desktop Icon, I get the error above.

All works well when I enable "Public Access". The issue occurs only when the public access is disabled and accessed through private link.

I made sure that the connectivity between the networks exist by RDP-ing into one of the session hosts from the Remote VM. The issue is only when trying to access through the Remote Desktop Client for AVD, with Private Access Disabled for Global, Feed and Connection. For DNS, I am using Private DNS Zones. Both the remote VNET and the Session Hosts VNET are linked to the Private DNS Zone. I have double checked all the FQDNs listed in the Private Links are configured in the Private DNS Zones (privatelink.wvd.microsoft.com and privatelink-global.wvd.microsoft.com).

Answer 1

Hi @Rajesh Joseph , I understand that you have setup Private Endpoint for AVD but getting "connection refused" in AVD client.

A few possibilities:

• Have you restarted AVD session hosts? Refer to Important note from this document:

After you've changed a private endpoint to a host pool, you must restart the Remote Desktop Agent Loader (RDAgentBootLoader) service on each session host in the host pool. You also need to restart this service whenever you change a host pool's network configuration. Instead of restarting the service, you can restart each session host.

• If you're using the Remote Desktop client for Windows on a private network without internet access and you're subscribed to both public and private feeds, you aren't able to access your feed.
• Did you create an unused placeholder workspace for the global sub-resource and make sure that it's not deleted? Note that you can't control access to the workspace used for the initial feed discovery (global sub-resource). If you configure this workspace to only allow private access, the setting is ignored. This workspace is always accessible from public routes.
• Have you validated Private Endpoint connection status for both workspaces and host pools?
• Did you enable RDP Shortpath? Using both Private Link and RDP Shortpath has some limitations.

References:

1. Known issues and limitations.
2. Supported Scenarios. Which one do you use - Both clients and session host VMs use private routes? Did you try - Clients use public routes while session host VMs use private routes?

Answer 2

Hi @Rajesh Joseph, from your latest explanation, it seems that you have not done these steps:

• Create a private endpoint for the feed sub-resource for each workspace you want to use with Private Link.
• Create a private endpoint for the connection sub-resource for each host pool you want to use with Private Link.

Refer to #2 and #3 from this document: Azure Virtual Desktop has three workflows with three corresponding resource types of private endpoints.

Answer 3

Hi @Silvia Wibowo - I did create those Private Endpoints. I have mentioned that in my original question:

When I enable "Private Link" and "Disable Public Access" (AVD workspace: Global & feed, Host Pool: Connections) and then try to connect from a remote VM (in another VNET in Azure connected to this Session Host VNET over a VPN

Anyways, it works now. However, I believe the documentation is not accurate.

Step 3: For each workspace in the feed, a DNS query is made for the address <workspaceId>.privatelink.wvd.microsoft.com. Step 5: When connecting a remote session, the .rdp file that comes from the workspace feed download contains the Remote Desktop gateway address. A DNS query is made for the address <hostpooId>.afdfp-rdgateway.wvd.microsoft.com.

None of the above entries are in the Private DNS Zone. You can see all the records in the private DNS zone privatelink.wvd.microsoft.com in the screenshot below. There are no such entries as mentioned in the documentation. But, it works!

Though it works, I see the below error message under my Session Host. I verified that the endpoints are reachable by RDPing into the Session host VM as a local admin, and I get the names resolved. But, the error message does not go away.

I also noticed that as soon as the Private Endpoint is enabled on the Session Hosts and Public access is disabled, the Health State of the Session Hosts are going into a "Shutdown" state for a considerable amount of time. Each time I tried, I had a different experience - sometimes, it is "Shutdown", sometimes it is "Upgrading".

This time, the status shows "Needs Assistance" and the troubleshooting message says "This health check verifies that the required AVD service and Geneva URLs are reachable from the session host, including the RdTokenUri, RdBrokerUri, RdDiagnosticsUri, and storage blob URLs for Geneva agent monitoring. If this check fails, it may be fatal." - as I mentioned above, I can resolve those names from the Session Host.

Answer 4

Hi @Rajesh Joseph How did you resolve your issue? I to am experiencing the same issue with the RDClient. I have Private Endpoints in place on the Session host pools and workspaces.

Answer 5

I had the same issue. Followed the documentation and created a separate workspace for global feed because I have multiple AVD environments. I was able to resolve it by restarting the machines in the pool.