Merge pull request #273366 from dknappettmsft/patch-6

PMEds28 · web-flow · commit c2e693afeb55 · 2024-06-24T11:59:50.000+01:00
AVD Private Link clarified scenarios
diff --git a/articles/virtual-desktop/includes/include-private-link-supported-scenarios.md b/articles/virtual-desktop/includes/include-private-link-supported-scenarios.md
@@ -0,0 +1,36 @@
+---
+author: dknappettmsft
+ms.author: daknappe
+ms.topic: include
+ms.date: 04/25/2024
+---
+
+1. All parts of the connection - initial feed discovery, feed download, and remote session connections for clients and session hosts - use private routes. You need the following private endpoints:
+   
+   | Purpose | Resource type | Target sub-resource | Endpoint quantity |
+   |--|--|--|--|
+   | Connections to host pools | Microsoft.DesktopVirtualization/hostpools | connection | One per host pool |
+   | Feed download | Microsoft.DesktopVirtualization/workspaces | feed | One per workspace |
+   | Initial feed discovery | Microsoft.DesktopVirtualization/workspaces | global | **Only one for all your Azure Virtual Desktop deployments** |
+
+1. Feed download and remote session connections for clients and session hosts use private routes, but initial feed discovery uses public routes. You need the following private endpoints. The endpoint for initial feed discovery isn't required.
+   
+   | Purpose | Resource type | Target sub-resource | Endpoint quantity |
+   |--|--|--|--|
+   | Connections to host pools | Microsoft.DesktopVirtualization/hostpools | connection | One per host pool |
+   | Feed download | Microsoft.DesktopVirtualization/workspaces | feed | One per workspace |
+
+1. Only remote session connections for clients and session hosts use private routes, but initial feed discovery and feed download use public routes. You need the following private endpoint(s). Endpoints to workspaces aren't required.
+
+   | Purpose | Resource type | Target sub-resource | Endpoint quantity |
+   |--|--|--|--|
+   | Connections to host pools | Microsoft.DesktopVirtualization/hostpools | connection | One per host pool |
+
+1. Both clients and session host VMs use public routes. Private Link isn't used in this scenario.
+
+> [!IMPORTANT]
+> - If you create a private endpoint for initial feed discovery, the workspace used for the global sub-resource governs the shared Fully Qualified Domain Name (FQDN), facilitating the initial discovery of feeds across all workspaces. You should create a separate workspace that is only used for this purpose and doesn't have any application groups registered to it. Deleting this workspace will cause all feed discovery processes to stop working.
+>
+> - 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.
+>
+> - IP address allocations are subject to change as the demand for IP addresses increases. During capacity expansions, additional addresses are needed for private endpoints. It's important you consider potential address space exhaustion and ensure sufficient headroom for growth. For more information on determining the appropriate network configuration for private endpoints in either a hub or a spoke topology, see [Decision tree for Private Link deployment](/azure/architecture/networking/guide/private-link-hub-spoke-network#decision-tree-for-private-link-deployment).
diff --git a/articles/virtual-desktop/private-link-overview.md b/articles/virtual-desktop/private-link-overview.md
@@ -13,39 +13,27 @@ You can use [Azure Private Link](../private-link/private-link-overview.md) with
 
 ## How does Private Link work with Azure Virtual Desktop?
 
-Azure Virtual Desktop has three workflows with three corresponding resource types of private endpoints:
+Azure Virtual Desktop has three workflows with three corresponding resource types to use with private endpoints. These workflows are:
 
 1. **Initial feed discovery**: lets the client discover all workspaces assigned to a user. To enable this process, you must create a single private endpoint to the *global* sub-resource to any workspace. However, you can only create one private endpoint in your entire Azure Virtual Desktop deployment. This endpoint creates Domain Name System (DNS) entries and private IP routes for the global fully qualified domain name (FQDN) needed for initial feed discovery. This connection becomes a single, shared route for all clients to use.
 
 2. **Feed download**: the client downloads all connection details for a specific user for the workspaces that host their application groups. You create a private endpoint for the *feed* sub-resource for each workspace you want to use with Private Link.
 
-3. **Connections to host pools**: every connection to a host pool has two sides - clients and session host virtual machines (VMs). To enable connections, you need to create a private endpoint for the *connection* sub-resource for each host pool you want to use with Private Link.
+3. **Connections to host pools**: every connection to a host pool has two sides - clients and session hosts. You need to create a private endpoint for the *connection* sub-resource for each host pool you want to use with Private Link.
 
 The following high-level diagram shows how Private Link securely connects a local client to the Azure Virtual Desktop service. For more detailed information about client connections, see [Client connection sequence](#client-connection-sequence).
 
 :::image type="content" source="media/private-link-diagram.png" alt-text="A high-level diagram that shows Private Link connecting a local client to the Azure Virtual Desktop service.":::
 
 ## Supported scenarios
 
-When adding Private Link with Azure Virtual Desktop, you have the following supported scenarios to connect to Azure Virtual Desktop. Each can be enabled or disabled depending on your requirements. You can either share these private endpoints across your network topology or you can isolate your virtual networks so that each has their own private endpoint to the host pool or workspace.
+When adding Private Link with Azure Virtual Desktop, you have the following supported scenarios to connect to Azure Virtual Desktop. Which scenario you choose depends on your requirements. You can either share these private endpoints across your network topology or you can isolate your virtual networks so that each has their own private endpoint to the host pool or workspace.
 
-1. Both clients and session host VMs use private routes. You need the following private endpoints:
-   
-   | Purpose | Resource type | Target sub-resource | Endpoint quantity |
-   |--|--|--|--|
-   | Connections to host pools | Microsoft.DesktopVirtualization/hostpools | connection | One per host pool |
-   | Feed download | Microsoft.DesktopVirtualization/workspaces | feed | One per workspace |
-   | Initial feed discovery | Microsoft.DesktopVirtualization/workspaces | global | **Only one for all your Azure Virtual Desktop deployments** |
+[!INCLUDE [include-private-link-supported-scenarios](includes/include-private-link-supported-scenarios.md)]
 
-1. Clients use public routes while session host VMs use private routes. You need the following private endpoints. Endpoints to workspaces aren't required.
+### Configuration outcomes
 
-   | Purpose | Resource type | Target sub-resource | Endpoint quantity |
-   |--|--|--|--|
-   | Connections to host pools | Microsoft.DesktopVirtualization/hostpools | connection | One per host pool |
-
-1. Both clients and session host VMs use public routes. Private Link isn't used in this scenario.
-
-For connections to a workspace, except the workspace used for initial feed discovery (global sub-resource), the following table details the outcome of each scenario:
+You configure settings on the relevant Azure Virtual Desktop workspaces and host pools to set public or private access. For connections to a workspace, except the workspace used for initial feed discovery (global sub-resource), the following table details the outcome of each scenario:
 
 | Configuration | Outcome |
 |--|--|
@@ -60,20 +48,13 @@ With the [reverse connect transport](network-connectivity.md#reverse-connect-tra
 | Public access **disabled** from all networks | Remote sessions are **denied** when either the client or session host is using a *public* route.<br /><br />Remote sessions are **allowed** when both the client and session host are using a *private* route. |
 | Public access **enabled** for client networks, but **disabled** for session host networks | Remote sessions are **denied** if the session host is using a *public* route, regardless of the route the client is using.<br /><br />Remote sessions are **allowed** as long as the session host is using a *private* route, regardless of the route the client is using. |
 
-> [!IMPORTANT]
-> - A private endpoint to the global sub-resource of any workspace controls the shared fully qualified domain name (FQDN) for initial feed discovery. This in turn enables feed discovery for all workspaces. Because the workspace connected to the private endpoint is so important, deleting it will cause all feed discovery processes to stop working. We recommend you create an unused placeholder workspace for the global sub-resource. 
->
-> - 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.
-> 
-> - If you intend to restrict network ports from either the user client devices or your session host VMs to the private endpoints, you will need to allow traffic across the entire TCP dynamic port range of 1 - 65535 to the private endpoint for the host pool resource using the *connection* sub-resource. The entire TCP dynamic port range is needed because port mapping is used to all global gateways through the single private endpoint IP address corresponding to the *connection* sub-resource. If you restrict ports to the private endpoint, your users may not be able to connect successfully to Azure Virtual Desktop. 
-
 ## Client connection sequence
 
 When a user connects to Azure Virtual Desktop over Private Link, and Azure Virtual Desktop is configured to only allow client connections from private routes, the connection sequence is as follows:
 
 1. With a supported client, a user subscribes to a workspace. The user's device queries DNS for the address `rdweb.wvd.microsoft.com` (or the corresponding address for other Azure environments).
 
-1. Your private DNS zone for **privatelink-global.wvd.microsoft.com** returns the private IP address for the initial feed discovery (global sub-resource).
+1. Your private DNS zone for **privatelink-global.wvd.microsoft.com** returns the private IP address for the initial feed discovery (global sub-resource). If you're not using a private endpoint for initial feed discovery, a public IP address is returned.
 
 1. For each workspace in the feed, a DNS query is made for the address `<workspaceId>.privatelink.wvd.microsoft.com`.
 
@@ -83,7 +64,10 @@ When a user connects to Azure Virtual Desktop over Private Link, and Azure Virtu
 
 1. Your private DNS zone for **privatelink.wvd.microsoft.com** returns the private IP address for the Azure Virtual Desktop gateway service to use for the host pool providing the remote session. Orchestration through the virtual network and the private endpoint uses TCP port 443. 
 
-1. Following orchestration, the network traffic between the client, Azure Virtual Desktop gateway service, and session host is transferred over to a port in the TCP dynamic port range of 1 - 65535. The entire port range is needed because port mapping is used to all global gateways through the single private endpoint IP address corresponding to the *connection* sub-resource. Azure private networking internally maps these ports to the appropriate gateway that was selected during client orchestration.
+1. Following orchestration, the network traffic between the client, Azure Virtual Desktop gateway service, and session host is transferred over to a port in the TCP dynamic port range of 1 - 65535.
+
+> [!IMPORTANT]
+> If you intend to restrict network ports from either the user client devices or your session host VMs to the private endpoints, you will need to allow traffic across the entire TCP dynamic port range of 1 - 65535 to the private endpoint for the host pool resource using the *connection* sub-resource. The entire TCP dynamic port range is needed because Azure private networking internally maps these ports to the appropriate gateway that was selected during client orchestration. If you restrict ports to the private endpoint, your users may not be able to connect to Azure Virtual Desktop. 
 
 ## Known issues and limitations
 
diff --git a/articles/virtual-desktop/private-link-setup.md b/articles/virtual-desktop/private-link-setup.md
@@ -32,12 +32,29 @@ In order to use Private Link with Azure Virtual Desktop, you need the following
 
 To use Private Link with Azure Virtual Desktop, you need to re-register the *Microsoft.DesktopVirtualization* resource provider on each subscription you want to use Private Link with Azure Virtual Desktop.
 
-> [!IMPORTANT]
-> For Azure for US Government and Azure operated by 21Vianet, you also need to register the feature for each subscription.
+Select the relevant tab for your scenario.
+
+# [Azure](#tab/azure)
+
+### Re-register the Azure Virtual Desktop resource provider
+
+Before you can use Private Link with Azure Virtual Desktop, you need to re-register the *Microsoft.DesktopVirtualization* resource provider. You need to do this for each subscription you want to use for Private Link with Azure Virtual Desktop:
+
+1. Sign in to the [Azure portal](https://portal.azure.com).
+
+1. In the search bar, enter **Subscriptions** and select the matching service entry.
+
+1. Select the name of your subscription, then in the section **Settings**, select **Resource providers**.
+
+1. Search for and select **Microsoft.DesktopVirtualization**, then select **Re-register**.
+
+1. Verify that the status of *Microsoft.DesktopVirtualization* is **Registered**.
+
+# [Azure US Gov and 21Vianet](#tab/us-gov-21vianet)
 
 ### Register Private Link with Azure Virtual Desktop (Azure for US Government and Azure operated by 21Vianet only)
 
-To register the *Azure Virtual Desktop Private Link* feature:
+For Azure for US Government and Azure operated by 21Vianet, first you need to register your Azure subscription for Private Link with Azure Virtual Desktop:
 
 1. Sign in to the [Azure portal](https://portal.azure.com).
 
@@ -49,9 +66,9 @@ To register the *Azure Virtual Desktop Private Link* feature:
 
 1. Select **Azure Virtual Desktop Private Link**, then select **Register**.
 
-### Re-register the resource provider
+### Re-register the Azure Virtual Desktop resource provider
 
-To re-register the *Microsoft.DesktopVirtualization* resource provider:
+Once you've registered your subscription, you need to re-register the *Microsoft.DesktopVirtualization* resource provider. You need to do this for each subscription you want to use for Private Link with Azure Virtual Desktop:
 
 1. Sign in to the [Azure portal](https://portal.azure.com).
 
@@ -63,26 +80,13 @@ To re-register the *Microsoft.DesktopVirtualization* resource provider:
 
 1. Verify that the status of *Microsoft.DesktopVirtualization* is **Registered**.
 
-## Create private endpoints
-
-During the setup process, you create private endpoints to the following resources, depending on your scenario.
-
-1. Both clients and session host VMs use private routes. You need the following private endpoints:
-   
-   | Purpose | Resource type | Target sub-resource | Endpoint quantity | IP address quantity |
-   |--|--|--|--|--|
-   | Connections to host pools | Microsoft.DesktopVirtualization/hostpools | connection | One per host pool | Four per endpoint |
-   | Feed download | Microsoft.DesktopVirtualization/workspaces | feed | One per workspace | Two per endpoint |
-   | Initial feed discovery | Microsoft.DesktopVirtualization/workspaces | global | **Only one for all your Azure Virtual Desktop deployments** | One per endpoint |
+---
 
-1. Clients use public routes while session host VMs use private routes. You need the following private endpoints. Endpoints to workspaces aren't required.
+## Create private endpoints
 
-   | Purpose | Resource type | Target sub-resource | Endpoint quantity | IP address quantity |
-   |--|--|--|--|--|
-   | Connections to host pools | Microsoft.DesktopVirtualization/hostpools | connection | One per host pool | Four per endpoint |
+During the setup process, you need to create private endpoints to the following resources, depending on your scenario.
 
-> [!IMPORTANT]
-> IP address allocations are subject to change as the demand for IP addresses increases. During capacity expansions, additional addresses are needed for private endpoints. It's important you consider potential address space exhaustion and ensure sufficient headroom for growth. For more information on determining the appropriate network configuration for private endpoints in either a hub or a spoke topology, see [Decision tree for Private Link deployment](/azure/architecture/networking/guide/private-link-hub-spoke-network#decision-tree-for-private-link-deployment).
+[!INCLUDE [include-private-link-supported-scenarios](includes/include-private-link-supported-scenarios.md)]
 
 ### Connections to host pools
 
@@ -560,7 +564,7 @@ To create a private endpoint for the *global* sub-resource used for the initial
 
 1. From the Azure Virtual Desktop overview, select **Workspaces**, then select the name of a workspace you want to use for the global sub-resource.
 
-   1. *Optional*: Instead, create a placeholder workspace to terminate the global endpoint by following the instructions to [Create a workspace](create-application-group-workspace.md?tabs=portal#create-a-workspace).
+   1. *Optional*: Instead, create a placeholder workspace to terminate the global endpoint by following the instructions to [Create a workspace](deploy-azure-virtual-desktop.md?tabs=portal#create-a-workspace).
 
 1. From the workspace overview, select **Networking**, then **Private endpoint connections**, and finally **New private endpoint**.
 
@@ -603,7 +607,7 @@ To create a private endpoint for the *global* sub-resource used for the initial
 
 # [Azure PowerShell](#tab/powershell)
 
-1. *Optional*: Create a placeholder workspace to terminate the global endpoint by following the instructions to [Create a workspace](create-application-group-workspace.md?tabs=powershell#create-a-workspace).
+1. *Optional*: Create a placeholder workspace to terminate the global endpoint by following the instructions to [Create a workspace](deploy-azure-virtual-desktop.md?tabs=powershell#create-a-workspace).
 
 1. In the same PowerShell session, create a Private Link service connection for the workspace with the global sub-resource by running the following commands. In these examples, the same virtual network and subnet are used.
 
@@ -681,7 +685,7 @@ To create a private endpoint for the *global* sub-resource used for the initial
 
 # [Azure CLI](#tab/cli)
 
-1. *Optional*: Create a placeholder workspace to terminate the global endpoint by following the instructions to [Create a workspace](create-application-group-workspace.md?tabs=cli#create-a-workspace).
+1. *Optional*: Create a placeholder workspace to terminate the global endpoint by following the instructions to [Create a workspace](deploy-azure-virtual-desktop.md?tabs=cli#create-a-workspace).
 
 1. In the same CLI session, create a Private Link service connection and the private endpoint for the workspace with the global sub-resource by running the following commands:
 
