Architecture diagram: Dual private endpoints would cause DNS conflicts?

[SteveBurkettNZ]

Let us know the feedback or general question

The AVD accelerator baseline architecture diagram shows that both the personal and pooled vnet's have separate private endpoint subnets, each containing private endpoint(s) for the common storage account and key vault(s).

The trouble comes with the DNS for these private endpoints; if using a common DNS server configuration, the DNS for one private endpoint for say the storage account will overwrite/conflict with the other when you deploy the second host pool?

The What is a private endpoint? doc says:

"Multiple private endpoints can be created with the same private-link resource. For a single network using a common DNS server configuration, the recommended practice is to use a single private endpoint for a specified private-link resource. Use this practice to avoid duplicate entries or conflicts in DNS resolution."

Should instead there be a common vnet/subnet used for the private endpoints? Else you'd have to have two DNS zones in use, each linked to different vnets.

The Azure Virtual Desktop Landing Zone Accelerator code only deploys the one host pool, if it had deployed both a personal and private pool like in the architecture diagram we probably would have bumped into this issue?

[danycontre]

@SteveBurkettNZ thanks for the feedback we are reviewing the issue.

[danycontre]

@SteveBurkettNZ The arch diagram is just a reference but agree the current one can be deceiving, we are working on an update to consolidate the host pools in one vNet and have only one private endpoint subnet.

Please check this version a let us know your feedback: avdaccelerator/workload/docs/diagrams/avd-accelerator-baseline-architecture.png at diagram-updates · Azure/avdaccelerator (github.com)

PS: the diagram only has 1 storage account as a reference, but 1 per host pool may be needed to avoid user profile concurrency, this depends on design and user workflows.

cc: @moisesjgomez @swathibhat1

[SteveBurkettNZ]

@danycontre : Yes, clearer! Thanks Dany.

Where you've got 'Azure Virtual Desktop subnet' labels, think it should read 'Session Host VMs (personal) subnet' and 'Session Host VMs (pooled) subnet', and drop the 'Session Host VMs (personal)' and 'Session Host VMs (pooled)' labels above.

Other feedback was:

• The positioning of the subnet labels in the middle above the (inner) dash-dot boxes made me interpret that those dash-dot boxes were showing the subnet which they are not; they're showing availability aware zone deployments. Think all the subnet labels should be where the Session Host VMs (personal) labels currently are (above-left the dotted boxes), or perhaps inside but left-aligned to the dotted box.
• Internet / Microsoft 365 shown as straight out to the right rather than via Azure Firewall (not best practice for security?) and also confuses as internet is also shown as going out via Azure Firewall at the top.
• Typo on the site-to-sight (sic) VPN

And I guess the Network topology and connectivity for Azure Virtual Desktop page could do with a mention of this configuration for virtual networks. i.e. something like 'We recommend using one virtual network containing separate subnets for each host pool, and one subnet to hold the private endpoints'. The Scenario 1 diagram shows just a single subnet with private endpoint mixed in with the session hosts, which is an overly simplistic view as you'd typically have more than one host pool?

[danycontre]

@SteveBurkettNZ thanks for the feedback we are working on updates.

[danycontre]

Diagrams updated.