Short answer

Private DNS at Azure landing-zone scale is a shared platform capability that ensures private endpoint names resolve consistently from workload, hub and hybrid networks through centrally governed zones and resolution paths.

Series context

This is Part 2 of the Azure DNS for Landing Zones series.

• Part 1: Private Endpoints Need Private DNS Zones
• Part 2: Private DNS at Scale in Azure Landing Zones
• Part 3: Designing Pod-Based Global DNS for Azure Landing Zones - coming after that

Architecture decision

Centralise ownership of approved Azure Private DNS zones and resolver patterns, while enabling product teams to provision supported private endpoints through automated platform interfaces.

When to use this pattern

Use this pattern when private endpoints span multiple subscriptions or virtual networks, when hybrid systems must resolve Azure private services, or when consistent private connectivity is required for regulated workloads.

Why Private DNS Becomes Hard at Scale

When an Azure service receives a private endpoint, applications still normally address the service using its familiar service hostname. DNS must guide that name to the private endpoint address from approved networks. In a small proof of concept, linking one private DNS zone to one virtual network can appear sufficient. In an enterprise platform, that approach quickly encounters ownership, duplication, hybrid resolution and lifecycle problems.

Product teams may create endpoints for storage, Key Vault, databases, container registries and other services in separate subscriptions. Environments may require isolation. On-premises systems may need to reach selected private services. Central networking teams need to understand the resulting paths without manually administering every application deployment.

Private DNS is therefore not just a network configuration detail. It is a platform capability that influences security boundaries, reliability and product-team autonomy.

Architecture takeaway: Private DNS must be designed as a shared platform service once workloads consume private endpoints across subscriptions and networks.

Private Endpoints and Split-Horizon DNS

A private endpoint maps an Azure service into a virtual network using a private IP address. Public DNS for the service continues to exist, while the private resolution path should return the endpoint address for clients that are intended to reach it privately. This is a split-horizon DNS problem: the correct answer depends on where the query originates and what access path is approved.

If name resolution is incorrect, clients may fail to connect, attempt a public path that policy prohibits, or reach the wrong endpoint arrangement. These failures are often misdiagnosed as firewall or application issues.

A platform design should treat endpoint provisioning and DNS registration as one capability. Creating a private endpoint without the intended resolution path is not a completed deployment.

Centralised Private DNS Zones

In a multi-subscription estate, Azure Private DNS zones are usually best owned centrally in a connectivity or shared-services subscription. Central ownership reduces duplicated zones, inconsistent records and uncertainty over which virtual networks are linked to which resolution source.

The platform can establish zones for approved Azure Private Link services and control zone links to the networks that require them. Product automation creates private endpoints and associates them with the supported central DNS pattern rather than creating arbitrary local zones.

Centralisation does not mean that the networking team must manually approve every routine endpoint. Terraform modules or deployment workflows can expose supported endpoint types and register them consistently. The division is useful: the platform owns resolution architecture, while the product owns its service instance and justified connectivity request.

Architecture takeaway: Central ownership should be paired with automation, so consistent resolution does not become a manual delivery bottleneck.

Environment separation requires deliberate thought. Some organizations use common central zones across environments where access and routing already provide adequate separation; others require stronger isolation. The decision should follow security and operational requirements rather than happen accidentally through portal defaults.

Private DNS Zone Sharding

Central ownership does not always require one flat zone shared across every product and environment. Private DNS zone sharding is an architecture pattern, not an Azure feature toggle: the platform deliberately establishes smaller resolution boundaries based on product or team ownership, environment, lifecycle, region, service type or workload class.

Sharded zones are isolated by default, so cross-zone and hybrid resolution must be designed explicitly. Azure DNS Private Resolver supports hub-and-spoke and hybrid paths across approved DNS boundaries, while selective virtual network links limit which workloads consume each shard. Linking every spoke to every zone removes much of the operational isolation that sharding is intended to provide.

The same boundary should be reflected in Azure role-based access control (RBAC) and Azure Policy: teams should manage only the DNS scope they own, while platform governance retains central oversight. Avoid both extremes: one large flat zone for unrelated products and a proliferation of shards for short-lived workloads without a durable operational reason.

This pattern can improve operational resiliency and change safety by containing the impact of record or link changes. It does not change the underlying availability commitment of the Azure DNS service.

Architecture takeaway: Use sharding when DNS ownership, change blast radius or environment isolation becomes more important than the simplicity of a single flat private DNS zone.

Hub-and-Spoke Considerations

Hub-and-spoke landing zones frequently place shared DNS capability in, or reachable from, the hub while workloads deploy in spoke virtual networks. DNS resolution must function from spokes and from any hybrid-connected network permitted to access services.

Virtual network links, routing, DNS server settings and firewall behavior need consistent design. A workload spoke should not need its own ad hoc DNS server simply because a private endpoint was created. Equally, central DNS services need sufficient availability and monitoring because a resolution outage can affect many products at once.

When workloads are segmented or have different regulatory boundaries, link and forwarding design should reflect those boundaries. Central service does not justify unnecessary cross-workload reachability.

Centralised Private DNS with Azure Firewall DNS Proxy

In a classic hub-and-spoke landing zone, Azure Firewall DNS Proxy can be one central resolution path for spokes. A workload uses the firewall private IP as its DNS server; the firewall then forwards the query to an upstream DNS server that can resolve the centrally governed Private DNS zones.

Spoke VM / workload
  -> DNS query to Azure Firewall private IP
  -> Azure Firewall DNS Proxy
  -> upstream DNS with access to linked Private DNS zones
  -> private A record / Private Endpoint IP

This can reduce the need to link every Private DNS zone to every spoke VNet, and it can keep the DNS answer used by clients aligned with DNS observed by firewall FQDN rules. The pattern is optional: the upstream DNS must resolve the required zones, and the spoke workloads must actually use the firewall proxy. DNS Proxy forwards queries; it does not make unlinked or unreachable private zones resolvable by itself.

For Azure Virtual WAN secured hubs, Private DNS zones cannot be linked directly to the Microsoft-managed virtual hub. A DNS extension VNet using Azure DNS Private Resolver or an approved forwarder pattern may be required. As with any central DNS dependency, availability, logging and operational ownership need explicit design.

Architecture takeaway: Azure Firewall DNS Proxy can reduce Private DNS zone link sprawl by making spokes use a central DNS path, but only when the firewall’s upstream resolver can actually resolve the linked Private DNS zones.

Azure DNS Private Resolver

Azure DNS Private Resolver provides managed inbound and outbound endpoints and forwarding rulesets for hybrid name-resolution patterns, reducing the need to operate custom DNS forwarder virtual machines for many scenarios.

An inbound endpoint enables connected networks to send DNS queries into Azure for names that Azure can resolve, including private zones exposed through the intended design. An outbound endpoint and forwarding rulesets allow Azure workloads to resolve specified domains through destinations such as enterprise DNS services.

The resolver belongs in the connectivity architecture: subnets, regional resilience, routing, forwarding rules, diagnostic needs and ownership must be planned. It is not merely a convenience feature added individually by each workload team.

Architecture takeaway: Name resolution is an operational dependency; resolver resilience, monitoring and ownership belong in architecture decisions.

Conditional Forwarding from On-Premises

Hybrid applications often require on-premises clients or servers to reach Azure services through private endpoints. Enterprise DNS servers can conditionally forward the appropriate Azure private-resolution queries toward Azure DNS Private Resolver inbound endpoints or another approved Azure resolution path.

The exact forwarding model must be documented and tested. Overly broad forwarding can create unexpected dependency or resolution behavior; incomplete forwarding creates intermittent failures depending on where clients operate. Include disaster recovery and secondary-region behavior in the design rather than addressing it only during an outage.

Operational troubleshooting should allow support teams to answer: which DNS server responded, which zone or rule applied, which private IP was returned and whether that IP is reachable from the requesting network.

Product and Platform Ownership Model

Clear responsibility avoids both uncontrolled sprawl and slow manual delivery:

• The platform team owns DNS architecture, approved private endpoint patterns, central zones, resolver capability, forwarding policy and monitoring.
• Product teams own their services, data-access decisions, endpoint requests and validation of application connectivity.
• Security and governance teams define public-access restrictions, evidence expectations and exception review.
• Operations teams need runbooks for DNS resolution failures, endpoint lifecycle and regional recovery.

This model can be implemented through a documented module catalogue. A module request may include service type, environment, spoke network, DNS association and ownership metadata, then deploy the endpoint according to the approved platform pattern.

Common failure modes

Frequent causes of trouble include:

• Product subscriptions creating duplicate private DNS zones for the same Azure service.
• Large flat zones shared by too many products, making routine DNS changes unnecessarily risky.
• Over-sharding zones for short-lived workloads, creating avoidable operational overhead.
• Linking too many virtual networks to too many zones, recreating a wide change blast radius.
• Sharded zones without a documented cross-zone or hybrid resolution path.
• RBAC that does not match the intended ownership boundary of each DNS shard.
• Missing virtual-network links, causing Azure-hosted clients to receive public answers or no useful answer.
• On-premises DNS without the required conditional forwarders.
• Private endpoint creation separated from DNS record lifecycle.
• Stale records after endpoints are replaced or deleted.
• DNS designs that do not account for disaster recovery or regional failure.
• Troubleshooting processes that check firewall rules without confirming resolution first.

These failure modes are preventable when private DNS is treated as shared platform engineering.

Governance and Naming

Governance should define which Azure services are expected to use private access, who can create endpoint resources, how public network access is constrained and how DNS associations are made. Azure Policy and infrastructure as code can help prevent unsupported patterns and collect compliance evidence.

Naming and metadata make operations easier. Endpoint resources, associated network interfaces and requests should identify product, environment, region, service owner and support contact where standards allow. DNS zones themselves usually follow Azure service conventions, so management metadata and deployment records are essential context.

Diagnostics should be included for resolver components and relevant networking controls. Review DNS patterns when introducing a new Private Link service type, a new region or a new hybrid-connectivity route.

Architecture checklist

• Private endpoint and DNS provisioning are delivered as one supported pattern.
• The design explicitly states whether Private DNS zones are flat, centralised or sharded.
• Sharding boundaries are based on ownership, environment, region, service type or lifecycle.
• RBAC and Azure Policy match the intended DNS ownership model.
• Virtual network links are selective and do not recreate a broad blast radius.
• Azure DNS Private Resolver is considered for cross-zone, hub-and-spoke or hybrid resolution.
• Zone size and record growth are monitored as operational signals.
• Central zone ownership and subscription placement are defined.
• Spoke network resolution and segmentation requirements are documented.
• Hybrid conditional forwarding has been tested from intended source networks.
• Azure DNS Private Resolver architecture includes resilience and ownership.
• Public access restrictions align with private-resolution expectations.
• Automation controls record creation and cleanup.
• Monitoring and troubleshooting runbooks include DNS-first verification.
• Recovery-region and regulated-boundary considerations are explicit.

Further reading

• Azure Networking
• Azure Landing Zones
• Azure DNS Private Resolver documentation
• Azure Firewall DNS settings
• Sharding private DNS zones - Azure DNS

Related architecture notes

• Private Endpoints Need Private DNS Zones
• Designing Azure Landing Zones for Product Teams
• Infrastructure as Code
• Sovereign Cloud
• Designing Pod-Based Global DNS for Azure Landing Zones - coming after that.

Summary

Private DNS at scale is a foundational Azure landing-zone capability. Central zones, governed private endpoint integration, managed resolution paths and clear product/platform ownership allow enterprises to use private Azure services consistently without turning every connection into a bespoke network project. When DNS is designed as part of the platform, secure connectivity becomes more reliable, observable and easier for product teams to consume.

Short answer

When an app stops working, it is always DNS.

Except when it is networking.

Except in Azure, where it is often both - because somebody created a Private Endpoint and forgot that DNS is now part of the deployment.

A Private Endpoint is not a complete deployment until clients resolve the service name to the private endpoint IP from the networks that need to use it. In Azure landing zones, Private DNS zones, virtual network links and resolver paths are part of the architecture, not an optional afterthought.

Private Endpoint plus broken DNS is incomplete private connectivity. The resource may be provisioned successfully, and routing may be available, but an application that resolves the public path or cannot resolve the service at all will not consume the intended private endpoint.

Series context

This is Part 1 of the Azure DNS for Landing Zones series.

• Part 1: Private Endpoints Need Private DNS Zones
• Part 2: Private DNS at Scale in Azure Landing Zones — publishing next
• Part 3: Designing Pod-Based Global DNS for Azure Landing Zones — coming after that

Part 1 focuses on the smallest useful design decision: whenever a workload is expected to use a private endpoint, its name-resolution path must be designed and tested with the endpoint.

The mistake

The familiar sequence is deceptively simple:

1. A product team creates a private endpoint for an Azure service.
2. The endpoint receives a private IP address in the workload network.
3. Routing, network security and public-access settings appear correct.
4. The application still cannot connect, or connects through a path that was not intended.

The investigation often begins with firewalls, user-defined routes, private endpoint approval or application credentials. Those may matter, but the basic question should come first: what IP address does the application actually receive when it resolves the Azure service hostname?

The failure is often that DNS still returns an unsuitable public path, that the required Private DNS zone was never created or linked, or that a central resolver cannot see the private zone. Another common failure is a locally created zone in one subscription while workloads elsewhere use a different resolution path.

The private endpoint changes the network path, but DNS decides whether the application uses that path.

This is why a private endpoint must not be treated as a stand-alone application resource. In a landing-zone architecture it consumes shared network and DNS capabilities.

How Private Endpoint DNS works

Applications usually continue to use an Azure service’s normal hostname. A storage client does not need a new bespoke application setting merely because a blob endpoint becomes private. Instead, Azure Private Link relies on DNS resolution producing the private endpoint path for networks that are allowed to use it.

For Blob Storage, the Microsoft-recommended Private DNS zone is:

privatelink.blob.core.windows.net

The intended private-resolution sequence is:

Application in product spoke VNet
  -> resolves the storage service hostname
  -> Private DNS resolution reaches privatelink.blob.core.windows.net
  -> private A record returns 10.40.10.20
  -> application connects to the private endpoint IP

The private A record maps the private-link service name to the endpoint network interface address. A private DNS zone group associated with the private endpoint can manage the relevant record association when it is configured against the correct zone.

The details matter:

• The public Azure service FQDN may remain the application-facing name.
• The recommended privatelink.* zone supports correct private endpoint resolution for that service type.
• A VNet linked to the Private DNS zone can resolve records in the zone when it uses the Azure-provided DNS path.
• A network using custom DNS, central forwarding or hybrid connectivity needs an approved resolver path to the linked zone.
• Public DNS and Azure Private DNS are different control planes. A public service name does not make a private record visible, and a private zone is not published to the internet.

Do not invent a custom substitute for the service’s required privatelink.* zone simply to make the naming look tidy. Custom application aliases can be useful at another layer, but the platform still needs the Azure Private Endpoint DNS integration required by the service.

What the platform should own

At enterprise scale, individual workload teams should not each decide how Azure Private Link DNS works. The platform team should own or govern the reusable resolution capability:

• Approved privatelink.* Private DNS zones for supported Azure service types.
• A central DNS resource group or subscription where central ownership is appropriate.
• The virtual network link strategy: which hub, spoke or resolution VNets can query each zone.
• Azure DNS Private Resolver and hybrid forwarding paths where workloads or on-premises networks need them.
• Policy and deployment guardrails that prevent unsupported DNS patterns.
• Naming, RBAC and ownership metadata for platform DNS resources.
• Cleanup processes so deleted or replaced private endpoints do not leave stale private records.

Central ownership does not mean a manual ticket for every endpoint. The preferred model is a supported infrastructure-as-code module or deployment workflow that allows a product team to request a private endpoint while the platform pattern supplies the approved DNS association.

Where a shared connectivity hub provides DNS resolution, Private DNS zones may be linked to the hub or other approved resolution VNet. Spoke and hybrid clients then reach the private answer through the documented resolver path. The design should make that path visible to support teams and testable from workloads.

What the product team should own

The application or product team remains accountable for why private connectivity is required and whether the application actually works through it. It should own:

• The justified request for a private endpoint.
• The Azure service instance consumed by the application.
• The workload connectivity requirement and permitted source networks.
• Application connection configuration and secret handling.
• Testing name resolution and connectivity from the workload network.
• A lifecycle or decommissioning request when the endpoint is no longer needed.

This separation avoids two poor outcomes: unrestricted DNS sprawl in product subscriptions and a platform team that becomes responsible for application behavior it cannot validate.

Minimal implementation pattern

Consider a generic product workload that accesses a storage account through Blob Storage:

This is a reference pattern rather than a complete production deployment. Subscription boundaries, access control, region, monitoring and infrastructure-as-code implementation should follow the platform standard.

1. Create or use the approved private zone

The platform either provisions this zone once for the supported service type or reuses the approved centrally governed zone:

az network private-dns zone create \
  --resource-group rg-dns-private-platform \
  --name privatelink.blob.core.windows.net

Avoid a separate copy of the same service zone in every product subscription unless the architecture deliberately requires isolated DNS boundaries and documents how clients select the correct zone.

2. Make the zone resolvable from the intended network

For a direct spoke-resolution pattern, link the product spoke VNet to the zone without VM autoregistration:

az network private-dns link vnet create \
  --resource-group rg-dns-private-platform \
  --zone-name privatelink.blob.core.windows.net \
  --name link-product-spoke-blob \
  --virtual-network /subscriptions/<subscription-id>/resourceGroups/rg-product-network/providers/Microsoft.Network/virtualNetworks/vnet-product-spoke \
  --registration-enabled false

This is a resolution link: the workload can query records in the private zone, while the link is not intended to register ordinary VM hostnames.

In a centrally resolved hub-and-spoke design, do not blindly link every zone to every spoke. Link zones and configure resolver paths according to the agreed model. If custom DNS or hybrid networks are involved, clients may need Azure DNS Private Resolver inbound endpoints and conditional forwarding rather than a direct spoke link.

3. Associate the endpoint with the private DNS zone

After the product’s private endpoint has been created, associate it with the approved zone through a private DNS zone group:

az network private-endpoint dns-zone-group create \
  --resource-group rg-product-network \
  --endpoint-name pe-product-blob \
  --name default \
  --private-dns-zone /subscriptions/<platform-subscription-id>/resourceGroups/rg-dns-private-platform/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net \
  --zone-name blob

The DNS zone group is the integration point between the endpoint and the platform-owned zone. The platform workflow should ensure that the endpoint type is paired with the correct recommended zone, rather than asking product teams to guess the mapping.

For the example endpoint, the private zone should contain the private record associated with 10.40.10.20. In a managed deployment this record is produced through the zone-group association; manually entered records should be reserved for carefully governed cases where automation is not suitable.

4. Verify resolution from the workload network

Run the test from a compute resource that uses the same DNS path as the application, not only from an administrator workstation:

nslookup <storage-account-name>.blob.core.windows.net

The result should lead to the intended private endpoint address:

Name:    <storage-account-name>.privatelink.blob.core.windows.net
Address: 10.40.10.20

Also test the application connection, public-access policy behavior and any hybrid source networks that are expected to consume the private service. A successful private IP lookup confirms DNS behavior; it does not replace end-to-end connectivity testing.

5. Document ownership and cleanup

For each endpoint, record:

• Product or workload owner.
• Service type and required private DNS zone.
• Spoke or resolver path used for name resolution.
• Endpoint and DNS zone group resource ownership.
• Expected private IP or validation method.
• Removal process when the service is retired.

Private endpoints have a lifecycle. DNS associations and stale records must be removed when endpoints are replaced or deleted, or troubleshooting becomes harder and name resolution can become misleading.

Resolver paths in hub-and-spoke landing zones

A small Azure-only deployment may work with a Private DNS zone linked directly to one spoke VNet. Enterprise landing zones often need a broader pattern:

Product spoke VNet
  -> approved Azure DNS resolution path
  -> Private DNS zone linked to resolution VNet
  -> private endpoint record

On-premises client
  -> enterprise DNS conditional forwarder
  -> Azure DNS Private Resolver inbound endpoint
  -> Private DNS zone linked in Azure
  -> private endpoint record

Azure DNS Private Resolver supplies managed inbound and outbound endpoints and forwarding rulesets. An inbound endpoint enables connected networks to query Azure private zones through a controlled Azure path. An outbound endpoint and linked ruleset enable Azure networks to forward selected namespaces to approved DNS servers elsewhere.

This does not remove design responsibility. The platform must decide where the resolver is deployed, which networks can reach it, which zones are linked, how forwarding is monitored and how a secondary region or recovery scenario behaves.

Centralised Private DNS with Azure Firewall DNS Proxy

A Private Endpoint DNS design does not always require linking the privatelink.* zone to every spoke VNet. In a classic hub-and-spoke Azure landing zone, one option is to link required Private DNS zones to the hub or DNS platform VNet, configure Azure Firewall as a DNS proxy, and configure spoke VNets to use the Azure Firewall private IP address as their DNS server.

Azure Firewall DNS Proxy acts as an intermediary. A spoke workload sends a DNS query to the firewall private IP, and the firewall forwards that query to its configured upstream DNS server. When the upstream path can resolve the platform-owned Private DNS zones, the product spoke receives the private endpoint answer through one centrally governed DNS path.

Instead of making every spoke a direct resolution link:

Private DNS zone
  -> linked to every spoke VNet

The platform can use this pattern where appropriate:

Spoke VM / workload
  -> DNS query to Azure Firewall private IP
  -> Azure Firewall DNS Proxy
  -> upstream DNS that can resolve Azure Private DNS zones
  -> private A record / Private Endpoint IP

This option can reduce Private DNS zone virtual network link sprawl, maintain a consistent DNS view between Azure Firewall FQDN rules and clients, simplify platform governance and reduce the temptation for workload subscriptions to create duplicate private zones.

It is not a universal rule. The following constraints are important:

• Spoke workloads must actually use the Azure Firewall private IP as their DNS server.
• The upstream DNS configured on Azure Firewall must be able to resolve the required Private DNS zones.
• When Azure Firewall uses Azure-provided DNS upstream, the required zone must be linked to the VNet context from which that Azure DNS query can resolve it.
• When Azure Firewall uses a custom DNS server upstream, that server must resolve or correctly forward queries toward the Azure Private DNS zones.
• DNS Proxy does not combine every zone in the tenant. It forwards each client query to the configured upstream DNS path.
• In an Azure Virtual WAN secured hub design, Microsoft-managed secured virtual hubs cannot be linked directly to Private DNS zones. A DNS extension VNet with a resolver or forwarder pattern may be required.
• This design centralises DNS dependency on the hub and firewall path, so availability, logging, operations and recovery ownership must be planned.

Architecture takeaway: Azure Firewall DNS Proxy can reduce Private DNS zone link sprawl by making spokes use a central DNS path, but only when the firewall’s upstream resolver can actually resolve the linked Private DNS zones.

Azure Firewall DNS Proxy implementation pattern

1. Enable DNS Proxy on Azure Firewall.
2. Configure spoke VNet DNS servers to use the Azure Firewall private IP.
3. Link required Azure Private DNS zones to the hub or DNS platform VNet.
4. Ensure Azure Firewall upstream DNS can resolve those zones.
5. Restart or renew DNS configuration on VMs after VNet DNS server changes.
6. Verify resolution from a workload VM in a spoke VNet.

The firewall-side configuration is intentionally concise:

az network firewall update \
  --name <firewall-name> \
  --resource-group <firewall-rg> \
  --enable-dns-proxy true

Configure the spoke VNet to send DNS queries to the firewall private IP:

az network vnet update \
  --name vnet-product-spoke \
  --resource-group rg-product-network \
  --dns-servers <azure-firewall-private-ip>

After the VNet DNS setting is updated, renew the guest network configuration or restart test VMs as required, then validate the storage lookup from the spoke:

nslookup <storage-account-name>.blob.core.windows.net

The expected answer remains the private endpoint address, such as 10.40.10.20. The difference is that the client reaches that answer through Azure Firewall DNS Proxy and its resolvable upstream path instead of through a direct zone link in every spoke.

Troubleshooting order

When an application fails after private endpoint deployment, use an order that reflects the architecture:

1. Resolve the service hostname from the workload network.
2. Confirm the answer is the intended private endpoint IP.
3. Confirm the private DNS zone is the correct Microsoft-recommended zone for the service.
4. Confirm the zone group and relevant VNet link or resolver path exist.
5. Only then continue with routes, network security, firewall policy, service approval and application authentication.

This order is not a claim that every outage is DNS. It is a way to avoid spending an hour inspecting a route table when the client never attempted to use the private address.

Common failure modes

• A private endpoint is created without a DNS zone group.
• The wrong privatelink.* zone is selected for the service subresource.
• A product subscription creates an unmanaged duplicate private zone.
• The approved zone exists but is not visible through the workload’s VNet link or resolver path.
• Hybrid DNS is expected to resolve Azure private endpoints without conditional forwarding to Azure.
• A record remains after an endpoint is removed or replaced.
• Engineers validate the endpoint resource but do not test DNS from the application network.

Each failure can be prevented through a platform module, policy checks, ownership records and a DNS-first validation step in release testing.

Architecture checklist

• The private endpoint request includes the required DNS integration.
• The service uses the appropriate Microsoft-recommended privatelink.* zone.
• Zone ownership and RBAC are defined by the platform.
• The workload network can reach a linked-zone or resolver-based resolution path.
• Zone-group association is created and governed alongside the endpoint.
• Resolution is tested from the application network and any approved hybrid source.
• Cleanup is part of the endpoint lifecycle.
• Troubleshooting runbooks check resolution before deeper network diagnosis.

Further reading

• Azure Private Endpoint DNS configuration
• Azure Private Endpoint DNS integration scenarios
• Azure Private DNS virtual network links
• Azure DNS Private Resolver endpoints and rulesets
• Azure Firewall DNS settings
• Azure Firewall DNS Proxy details
• Private endpoint inspection in an Azure Virtual WAN secured hub
• Azure CLI private endpoint DNS zone groups

Related architecture notes

• Azure Networking
• Private DNS at Scale in Azure Landing Zones — publishing next.
• Designing Pod-Based Global DNS for Azure Landing Zones - coming after that.

Summary

A Private Endpoint delivers a private network attachment, not a finished application connection. The finished pattern includes the approved Private DNS zone, the correct record association, a VNet link or resolver path and a test from the network where the application runs. Treating these elements as one platform capability is the difference between private connectivity that is repeatable and private connectivity that fails only after deployment.

Short answer

Azure Landing Zones for product teams are governed platform foundations that standardise subscriptions, connectivity, identity, policy and observability while giving application teams a clear, automated route to deploy and operate their workloads.

Architecture decision

Treat the landing zone as a versioned platform product owned around shared controls and supported patterns, while product teams retain responsibility for workload-specific architecture and operation.

When to use this pattern

Use this pattern when multiple products or environments require consistent Azure controls, when private connectivity and identity governance must scale beyond one project, or when regulated workloads require traceable policy and operational evidence.

Problem Statement

Enterprises rarely struggle to create a single Azure subscription. The harder problem is providing a repeatable environment for many products, stages and teams while retaining confidence in identity, connectivity, policy, monitoring, cost and regulatory boundaries.

Without a platform approach, projects make local decisions: one chooses its own private DNS arrangement, another assigns broad roles to a pipeline, and a third discovers logging or disaster recovery only before go-live. Those differences increase delivery effort and operational risk.

An Azure landing zone is the set of foundational decisions and automated capabilities that product teams consume. It should be opinionated where shared security and operations require consistency, and flexible where workload requirements genuinely differ.

Architecture takeaway: A landing zone is a consumed platform capability, not only an initial subscription and network deployment.

Platform Versus Project Mindset

A project mindset builds foundations for a delivery milestone. A platform mindset creates a supported product that must serve multiple workloads over time. The distinction affects priorities:

• Reusable capability matters more than a one-off portal configuration.
• Clear consumer interfaces matter as much as the underlying Azure resource graph.
• Versioning, operational ownership and upgrade paths matter after initial deployment.
• Exceptions are design inputs to evaluate, not quiet divergence from standards.

The platform team does not need to own every application resource. It should own the shared rules and building blocks that let application teams take appropriate responsibility for workloads.

Management Group and Subscription Design

Management groups provide a policy and access-assignment hierarchy. They should be designed around control requirements rather than copying an organizational chart that changes frequently. A common pattern distinguishes platform capabilities from workload landing zones and separates production from non-production or regulated scopes where the control baseline materially differs.

Subscriptions are useful boundaries for policy, access, quotas, billing visibility and blast radius. A product may receive distinct subscriptions for production and non-production, with additional boundaries where data sensitivity, connectivity or regulatory requirements demand them.

Subscription design should answer:

• Who owns workload cost and operational response?
• Which baseline policies apply?
• Which deployment identities may create resources?
• Which networks and regions are available?
• How does a product transition from experimentation to production support?

Over-fragmentation adds administration, while under-separation makes authorization and evidence difficult. The appropriate balance follows workload ownership and risk.

Subscription Vending

Subscription vending converts architecture standards into an onboarding workflow. A request should capture product identity, environment, owner, support contact, data classification, connectivity need, region and budget information. Automation can then place the subscription in the correct management group and attach the platform baseline.

A vended subscription might receive:

• Naming and tagging baseline.
• Role assignments for approved product and deployment groups.
• Budget and ownership information.
• Diagnostic settings and security integration.
• Network onboarding or documented connectivity choices.
• Policy assignments inherited through the intended scope.

This process gives product teams a usable starting point and gives platform owners an auditable record of why an environment exists.

Architecture takeaway: Subscription vending should establish ownership, controls and operational visibility at the moment a team receives its environment.

Network and DNS Baseline

Networking is where landing zones often succeed or fail in daily use. Product teams require predictable options for inbound access, outbound dependencies, hybrid connectivity and private Azure services. Hub-and-spoke or Azure Virtual WAN can provide shared connectivity and inspection, but the selected model must be supported with routing ownership and monitoring.

Private endpoints make private DNS a platform concern. If every team creates private DNS zones independently, resolution becomes unreliable across spokes and connected on-premises networks. A landing zone should define central private DNS zone ownership, zone-link behavior, Azure DNS Private Resolver or forwarding arrangements where needed, and automation for supported private endpoint types.

The baseline should be documented in consumer terms: how a product requests connectivity, what is centrally managed, which traffic is inspected and how incidents are diagnosed.

Architecture takeaway: Private endpoint adoption makes DNS design and lifecycle automation part of the landing-zone product.

Identity and Role Assignment Model

Human and workload identities should be designed separately. Teams can receive access through Microsoft Entra ID groups with defined ownership and review. Privileged platform administration should be limited, monitored and eligible through controlled workflows where appropriate.

Deployment pipelines should use governed identities with only the permissions required for their deployment boundary. Avoid embedding long-lived secrets in product workflows where managed identities or workload identity federation provide a better control.

The landing zone also needs emergency access, role-change processes and an evidence path for audits or incidents. Least privilege is not a slogan; it is a maintained relationship between team responsibility and permitted action.

Azure Policy Baseline

Azure Policy turns selected standards into enforceable or measurable platform behavior. A baseline may require diagnostic settings, constrain locations, restrict insecure exposure, deploy supporting agents or report non-compliance. Policy should be treated as code: versioned, reviewed, tested, deployed progressively and associated with an exception process.

Do not begin with the maximum possible number of deny policies. A landing zone needs a baseline that prevents unacceptable outcomes while giving teams clear remediation. Audit and deploy-if-not-exists effects can establish visibility and configuration; deny effects should be intentional and understood by consumers.

Regulated workload scopes may add approved-service lists, restricted regions or more stringent connectivity requirements. Those additions should be traceable to a control need.

Observability and Security Operations

A subscription is not production-ready merely because deployment succeeds. Logs and platform metrics need defined destinations, retention and ownership. Security findings need operational routing. The platform should provide monitoring integration and product teams should understand which alerts they own.

Useful platform-level signals include policy compliance, subscription inventory, role assignment changes, network and firewall diagnostics, Defender recommendations, deployment failures and cost anomalies. Incident investigation is faster when those signals are consistent across products.

For sovereign or sensitive workloads, evidence collection and log data residency also require architecture review.

Product Team Onboarding

Onboarding should include documentation, sample deployment code and a small number of decisions the product team genuinely owns. A team needs to know:

• How to obtain subscriptions and deployment identities.
• How to consume network, DNS and private endpoint patterns.
• Which policies are applied and how to remediate or request an exception.
• Where logs, cost and security findings are visible.
• How platform changes and module versions are communicated.

Platform support should observe repeated questions and use them to improve documentation, modules or automation rather than accepting permanent manual intervention.

Common failure modes

Common landing-zone failures include designing only for one initial workload, using management groups as a static organization chart, allowing uncontrolled private DNS creation, assigning excessive rights to deployment identities, applying policies without consumer guidance and treating operational monitoring as a later project phase.

Another mistake is presenting governance and developer experience as opposites. A well-designed platform creates fast, safe paths for standard delivery and a clear process for assessed exceptions.

Architecture checklist

• Control requirements and workload classifications are understood.
• Management group scopes and subscription boundaries have clear purposes.
• Subscription vending attaches ownership, access, monitoring and policy consistently.
• Network, private endpoint and DNS patterns are documented and automated.
• Human and deployment identities follow least privilege.
• Policy is versioned, tested and linked to exception handling.
• Observability and security response have owners.
• Product onboarding is usable and measurable.
• Regulated requirements include evidence and recovery design.

Further reading

• Azure Landing Zones
• Infrastructure as Code
• Azure Networking

Related architecture notes

• Private Endpoints Need Private DNS Zones
• Identity & Security
• Platform Engineering

Summary

Azure landing zones for product teams should be delivered as a platform product: a governed, automated foundation that reduces repeated architecture decisions and improves evidence, security and operational consistency. The best landing zone allows teams to focus on their product while knowing that identity, networking, policy and visibility are intentionally designed around them.

However, I still needed to configure web servers, failover clusters for SQL Always On groups, and other elements. To accomplish this, I decided to explore Ansible. Ansible is an open-source automation tool that allows IT professionals to automate tasks like configuration management, application deployment, and task automation. Ansible uses a simple, human-readable language called YAML to define tasks and configurations, and it can be easily integrated into existing workflows and toolchains.

In my current setup, I installed Ansible on my PC using WSL (Windows Subsystem for Linux) and Ubuntu. WSL is a compatibility layer in Windows that enables running Linux binaries natively on Windows. It provides a Linux-compatible kernel interface that allows Linux binaries to run on Windows without the need for a traditional virtual machine. Installing Ansible on WSL and Ubuntu is fairly straightforward.

After installing Ansible, I created a project folder and an inventory.txt file inside the project folder using the command sudo vi inventory.txt In the inventory.txt file, I added the hosts that I wanted to deploy my configuration, one is a VM running on my PC and one is a VM deployed in Azure with my Terraform code. I divided the servers into two groups: [Window] and [azure]. You can add as many servers as you want to each of the groups.

The next step was to configure a variable for each VM to allow communication between Ansible and Windows OS. It’s essential to remember that winrm must be configured on the Windows VM. You can run a PowerShell script to configure listeners and generate a self-signed certificate required for authentication. The PowerShell script can be found here

For Azure VMs, I also had to configure NSGs and a Firewall to allow communication from my home PC on port 5986 used by Ansible.

Now, let’s create a playbook. An Ansible playbook is a collection of tasks that are executed against a set of hosts defined in an inventory file. Playbooks are written in YAML format and define the desired state of the hosts. Playbooks can be used for a wide range of automation tasks, including configuration management, application deployment, and task automation.

A playbook consists of one or more plays, and each play consists of a set of tasks to be executed on the hosts. Tasks are executed in order, and each task defines a module to be run on the host and the parameters for that module.

In my playbook, I do a few things:

• create a folder _tmp
• create a demo.txt file inside a folder that was created in the previous file
• copy PowerShell script that will create new failover cluster with a single node
• install Windows Security Updates
• install IIS on both VMs
• install Failover Cluster feature
• install Failover Cluster Management Tools

Here is my playbook file pingtest.yaml

Okay, now that we have everything configured, let’s run the playbook and see the end result. To execute a playbook, we run the below command: ansible-playbook pingtest.yaml -i inventory.txt

Everything worked as expected (it didn’t straight away and it took me a good few hours to sort everything out 😂).

Next, verify the IIS deployment:

As you can see, IIS has been successfully installed. What about Failover Cluster roles? Here they are too, with files and folders as well :)

Summary

This example used Terraform to provision Azure infrastructure and Ansible to configure Windows server roles after deployment. The combination is useful when responsibilities are clear: Terraform owns cloud resource state, while configuration automation manages operating-system configuration in a controlled, repeatable way.

Before production use, protect inventory secrets, restrict WinRM exposure, use appropriate authentication and certificate practices, test idempotency and include patching and rollback in the operating model. Automation is most valuable when it reduces drift and leaves a reviewable record of platform changes.

Recently, I had the opportunity to explore Power Apps and was amazed by its capabilities. One of the internal projects I worked on was creating a Tuck Shop app, which proved to be a fun and rewarding experience.

The Tuck Shop app was designed to simplify the process of ordering snacks and drinks at HTG’s canteen. With Power Apps, I was able to create a user-friendly interface that allowed colleagues to scan the barcode of the items they wanted to purchase, view their total cost and purchase history, confirm whether an item was already paid for, and submit an order with just a few clicks.

Power Apps made it easy to integrate the app with other Microsoft services such as SharePoint and Microsoft Teams. This meant that the app could be accessed by anyone with the right permissions, making it an ideal solution for managing purchases in the HTG Tuck Shop.

Overall, my experience with Power Apps was extremely positive. Its low-code platform allowed me to create a fully functional application without the need for extensive coding knowledge, and its seamless integration with other Microsoft services made it a versatile and efficient solution for the Tuck Shop project.

If you are looking for a powerful and user-friendly platform for creating custom business applications, Microsoft Power Apps is worth exploring. Its low-code approach, coupled with integration with other Microsoft services, makes it a useful tool for application development.

Summary

This small application demonstrated how Power Apps, SharePoint and Teams can support a practical internal workflow with minimal custom development. For a production business application, the next architecture questions would include data ownership, access groups, audit requirements, environment strategy, support and application lifecycle governance.

Updated note (2026): Shared Image Gallery (SIG) is now Azure Compute Gallery. Confirm current Azure Virtual Desktop session host deployment options before following this historical portal workflow.

This is a quick post related to the Azure Virtual Desktop Host Pool update process. Microsoft recommends rebuilding the session host from the latest, fully patched image stored in Azure Compute Gallery (formerly Shared Image Gallery). This is an overall smooth and easy process; however, the issue I had was around the host prefix counter. Every new host added to the pool gets an incremental number unless you delete all the session hosts from the pool. In my case, I didn’t want to delete the host in case I need to roll back and a customer wanted the host numbers to start from 0-10. The solution to this is pretty simple, modify the ARM Template before hitting Create button. Follow the normal process of adding a new host to the host pool but at the very last step, instead of clicking Create, click on Download a template for automation

• Now select Parameters

• now look for vmInitialNumber

• Change the value from 1, in my case, to 0 or any other number that you want to start VM numbers from.
• Now click Deploy.

Summary

Changing vmInitialNumber allowed an AVD session-host deployment to start at the required naming sequence while preserving existing hosts for rollback. The portal and deployment templates can change over time, so confirm the current session-host registration workflow and securely handle registration tokens before applying this approach in production.

For an enterprise platform, naming conventions should be predictable, but host replacement and rollback safety are more important than cosmetic numbering. Automating the host lifecycle through reviewed templates or infrastructure as code provides a more dependable long-term pattern.

Updated note (2026): Azure Virtual Desktop (AVD) is the current product name. Azure Active Directory referenced in this historical announcement is now Microsoft Entra ID.

Microsoft announced in June 2021 that Windows Virtual Desktop (WVD) would be rebranded as Azure Virtual Desktop (AVD).

The rebrand reflected Microsoft’s broader positioning of the service as a cloud VDI and application-delivery platform for hybrid work. For enterprise architecture, the meaningful point was not simply the product name: AVD became an increasingly important platform workload requiring secure identity integration, scalable host management, profile storage, endpoint controls and monitoring.

At announcement time, Microsoft also described new capabilities and pricing options for remote application streaming.

Some of the capabilities discussed in that historical announcement included:

Enhanced Support for Microsoft Entra ID

• Microsoft Entra ID, then named Azure Active Directory, is a critical service used by organizations to manage user access to important apps and data and maintain strong security controls. At announcement time, Microsoft also described support for joining Azure Virtual Desktop virtual machines directly to that identity service.

Multi-Session Management

• Microsoft Endpoint Manager allows you to manage policies and distribute applications across devices.

Microsoft’s original announcement is available in Azure Virtual Desktop: The desktop and app virtualization platform for the hybrid workplace.

Summary

Azure Virtual Desktop is now the established product name. For new deployments, focus on current AVD documentation and design the service as part of a governed Azure platform: identity, network paths, image management, user profiles, monitoring and operational ownership should be explicit from the start.

Updated note (2026): Windows Virtual Desktop is now Azure Virtual Desktop (AVD), and Azure Active Directory is now Microsoft Entra ID. Screenshots retain the names shown when this article was published.

Since Azure Virtual Desktop (formerly Windows Virtual Desktop) uses Microsoft Entra ID for authentication, FIDO2 security keys can also be used to secure applications and desktops hosted on Azure Virtual Desktop.

In this post, I will demonstrate how to enable FIDO2 support in Microsoft Entra ID for AVD.

First of all, we need to enable FIDO2 support in Microsoft Entra ID. Log in to the Azure portal and then navigate to Microsoft Entra ID Authentication methods.

Under Policies blade, select FIDO2. Now under 1) Enable, click on Yes, next under 2) Target select All users or specific pilot group or individual user. In my demo, I will only target one user. Now under 3) General, Allow self-service setup, this will allow users to register their security keys

Now as the Azure part is already configured, we can log in to the Office.com portal and register our security key. Once you are logged in, click on your initials in the top right corner and select View Account

Now click on Security Info on the left-hand side, or in the middle of the screen

Now you should see currently allowed authentication methods. Click Add a method and choose Security Key from the drop-down menu

Select the correct device type you are using. For this demo I used USB Yubikey hence I selected USB Device

Ok, now it’s time to plug the key into the USB port and start the registration

Select PIN for your key

Touch your security key to finish registration

That is the key now registered with my test account and ready to use. Let us try it with Azure Virtual Desktop.

Launch Microsoft Remote Desktop client and hit subscribe. On the Microsoft signing page, click on Sign-in options. You should now see the below options, click on Sign in with Windows Hello or a security key

Now, type in the PIN that we set up earlier on for our key

Touch the key

And we are in!

The same process applies when accessing AVD via the web client.

Summary

FIDO2 security keys provide a phishing-resistant authentication option for Azure Virtual Desktop access through Microsoft Entra ID. Before using this approach in production, validate supported clients, authentication-method policy scope, Conditional Access requirements, recovery processes and service-desk support for lost or replaced keys.

The architecture takeaway is that a virtual desktop platform is only as secure as its access path: strong user authentication should be designed alongside session controls, application authorization and operational monitoring.

Updated note (2026): Azure Active Directory is now Microsoft Entra ID. This article originally described a preview-era activation flow; CAE is now a current capability with behavior and support requirements documented by Microsoft. Use the current Microsoft Learn guidance when designing or troubleshooting deployments.

Why Token Lifetime Is Not Enough

Cloud applications commonly authorize a session using an access token. A token is valid for a period and avoids authentication on every request. That model creates an important security question: what happens when a user’s risk or authorization changes while the token remains valid?

Consider an employee account that is disabled, a password reset following suspected compromise, a user moved away from a trusted location, or an administrator revoking sessions. Waiting until an existing token naturally expires can leave access available for longer than the business risk allows.

Security architecture should therefore distinguish between initial authentication and continuous enforcement. Strong authentication reduces the likelihood of unauthorized sign-in. Conditional Access determines whether access should be permitted under evaluated conditions. CAE helps supported applications learn about certain changes and enforce them sooner during an existing session.

What Continuous Access Evaluation Does

CAE allows supported resource providers and clients to respond to critical events and Conditional Access policy changes in near real time. Instead of relying only on a fixed token interval, a CAE-capable service can challenge a client to obtain a new token when the service becomes aware of an event that affects access.

Microsoft documents critical events that can trigger this type of response, including:

• A user account being deleted or disabled.
• A password being changed or reset.
• Multifactor authentication being enabled for a user.
• An administrator explicitly revoking user sessions or refresh tokens.
• Elevated user risk detected by Microsoft Entra ID Protection.

Conditional Access location policy enforcement can also respond when the relevant network location changes, provided the application, client and policy combination supports CAE behavior.

This does not mean every session everywhere is instantly disconnected. CAE depends on supported clients, resource providers, policy configuration and available signals. An architecture decision must account for that support boundary.

Relationship to Conditional Access

Conditional Access is the policy layer: it expresses conditions such as user, application, device, location or risk and specifies controls such as multifactor authentication or blocking access. CAE complements that policy layer by enabling faster reevaluation for supported scenarios while a session is active.

For example, an organization may define trusted network locations for sensitive Microsoft 365 resources. If a CAE-capable session moves from a trusted network to an untrusted location, the resource can require the client to refresh access and apply the Conditional Access decision without waiting for a normal token expiry cycle.

CAE is not a replacement for Conditional Access policy design. Poorly scoped policies, incomplete exclusions, missing emergency-access planning or unsupported applications remain architectural concerns regardless of CAE.

Session Revocation Scenarios

CAE is particularly relevant to security operations and identity lifecycle processes:

Account Disablement

When a user leaves the organization or an account is disabled during incident response, supported sessions can lose access more quickly. This reduces exposure compared with relying only on normal token expiry.

Password Reset or Credential Concern

A password reset can be part of responding to suspected credential compromise. CAE helps make that action meaningful for supported cloud application sessions, but the response plan should also assess device security, authentication methods and any workload identities involved.

Administrator Revocation

An administrator may revoke sessions when investigating risky sign-ins or when a user device is lost. This is an operational control that should be documented and tested by the identity and security operations teams.

Location Change

With appropriate Conditional Access policies, changing from an allowed to a disallowed network location can lead to faster policy enforcement for CAE-capable applications. Network location definitions and named location governance therefore become part of identity architecture.

Design and Verification Approach

The original preview-era instruction to select an Enable preview option is no longer a suitable configuration tutorial. A current design approach is:

1. Identify applications and user groups where rapid enforcement is important, such as sensitive Microsoft 365 access or administrator workflows.
2. Review Microsoft’s current list of CAE-supported clients, resource providers and Conditional Access scenarios.
3. Confirm that Conditional Access policies express the intended controls and that emergency access accounts are appropriately protected.
4. Validate session revocation and location-change behavior with representative supported clients.
5. Monitor sign-in and audit information during testing and record expected operational response steps.
6. Include unsupported or legacy application behavior in residual-risk decisions.

This validation should take place in a controlled tenant or pilot scope before it influences broad access policies.

Client and Application Support Considerations

CAE is valuable precisely because applications participate in enforcement. That participation means client and resource support matters. Older clients, some protocols, custom applications or third-party applications may not behave in the same way as current supported Microsoft 365 applications.

Architects should not describe the environment as protected by CAE merely because Microsoft Entra ID is in use. They should document:

• Which resources and client types are expected to support CAE.
• Which Conditional Access policies depend on location or other reevaluation signals.
• How non-CAE-capable applications are controlled.
• How security operations revoke sessions and validate the outcome.
• What logs or investigations demonstrate that enforcement occurred.

Where a business application requires rapid revocation but does not support suitable controls, that gap needs risk treatment rather than assumption.

Identity Governance and Regulated Environments

In regulated or sovereign platform contexts, the ability to respond quickly to critical identity events contributes to operational assurance. An organization may need to demonstrate that privileged or sensitive access is governed, monitored and revoked through defined procedures.

CAE should sit within a broader identity architecture that includes Microsoft Entra ID roles, Privileged Identity Management where appropriate, strong authentication, Conditional Access, identity lifecycle management, access reviews, logging and incident response. It is one control in a layered design.

Limitations and Operational Considerations

CAE reduces response time for supported scenarios; it is not a guarantee of immediate enforcement across every application and connection. Network interruptions, unsupported clients, service behavior and policy scope can affect results. Teams should keep current with Microsoft documentation and re-test critical access scenarios after significant policy, client or application changes.

Summary

Continuous Access Evaluation strengthens cloud access design by helping supported Microsoft Entra ID sessions react sooner to critical identity events and relevant Conditional Access changes. It addresses a gap that token lifetime alone cannot solve, but its value depends on supported applications, sound policy design and tested operational procedures.

For enterprise Azure and Microsoft 365 architecture, CAE should be treated as part of a broader identity and security control model: strong authentication, least privilege, governed policy, visibility and dependable incident response.

Further Reading

• Continuous access evaluation in Microsoft Entra
• Conditional Access documentation
• Revoke user access in Microsoft Entra ID

Updated note (2026): SMB Multichannel for Azure Files is no longer a preview enrollment workflow. Current Microsoft documentation states that Azure Files supports SMB Multichannel on SSD file shares and that it is enabled by default for Windows clients in all Azure regions. Validate current constraints in Microsoft Learn before production deployment.

What SMB Multichannel Does

SMB Multichannel is part of the SMB 3.x protocol family. Instead of establishing a single client-to-file-share connection, a compatible client can open multiple network connections for the same SMB session. The client can use available network interfaces and Receive Side Scaling (RSS) capabilities to distribute I/O across processors and paths.

For Azure Files, the practical outcome is improved throughput for workloads that need to move large amounts of data between a supported Windows client and an SSD file share. It is not an automatic answer to every performance issue. Latency, storage tier, file size, I/O pattern, VM sizing, network path and application behavior still matter.

Why It Matters for Azure Files

Azure Files provides managed SMB shares without requiring an organization to operate file server virtual machines. For workloads that already use Azure Files and need greater throughput from a client or a small set of clients, SMB Multichannel can make better use of the available network and storage capability.

This is most useful when a performance assessment shows that the workload is constrained by a single SMB connection or client-side network processing, rather than by storage limits or application design. Architecture work should begin with workload measurements and expected service limits, not with enabling features in isolation.

Where It Helps

Potential scenarios include:

• Large file transfer and content-processing workloads where clients perform sustained reads or writes.
• Media, engineering or analytical processing in which a small number of machines access large datasets.
• High-throughput application shares that are already suitable for managed SMB storage.
• Some Azure Virtual Desktop (AVD) profile or container scenarios, where relevant and validated by performance testing.

Small files, metadata-heavy operations or applications dominated by latency may see limited benefit. Profile storage for AVD also requires particular care because user experience depends on resilience and supportability as well as throughput.

Requirements and Constraints

Microsoft documentation currently identifies the following important requirements:

• Azure Files SMB Multichannel is supported on SSD file shares.
• Clients must use a supported SMB 3.x configuration and should be kept current with recommended operating system updates.
• Windows clients support SMB Multichannel, which is enabled by default in normal current configurations.
• A maximum of four channels applies to Azure Files SMB Multichannel.

Consult current Azure Files scalability and SMB documentation when selecting storage tier, redundancy and client sizing. A design based on an old preview limit or a laboratory workload can produce disappointing results in production.

SSD File Shares and Storage Accounts

The original version of this article described premium file shares in FileStorage accounts during preview. In current design discussions, it is clearer to refer to SSD file shares and validate the precise Azure Files account and tier configuration against Microsoft’s current service documentation.

Use an SSD file share where the workload requires predictable high performance and the cost model is justified by measured requirements. Record the target workload profile, expected throughput, IOPS, capacity, resilience and backup needs as part of the platform decision.

Network Considerations

SMB 3.x and TCP 445

SMB traffic to Azure Files uses TCP 445. Clients must be able to reach the intended file share over an approved network route. For Azure-hosted workloads this may be straightforward; for on-premises or remote clients, network policies and service-provider restrictions require explicit validation.

Private Endpoints and DNS Resolution

Enterprise platforms commonly use private endpoints for storage access. In that architecture, correct private DNS resolution is essential: the storage account name must resolve to the approved private endpoint address from each connected network that uses the share. A throughput feature cannot correct DNS misrouting or an unintended public access path.

Private endpoint design should therefore align with landing-zone DNS patterns, hub-and-spoke connectivity, conditional forwarding from on-premises networks and ownership of private DNS zone links. Test name resolution and the connection path before measuring performance.

Client OS and RSS-Capable Interfaces

Client operating systems need supported SMB behavior and current patches. RSS-capable network interfaces allow processing to scale across CPUs, which is one of the ways SMB Multichannel can increase throughput. The client VM size and NIC capabilities should be appropriate for the throughput target; an undersized client remains a bottleneck.

Check the Current Configuration

Use Azure CLI to inspect the SMB Multichannel setting on an Azure storage account:

az storage account file-service-properties show \
  --resource-group <resource-group> \
  --account-name <storage-account> \
  --query "protocolSettings.smb.multichannel.enabled"

Depending on when an account was created and whether the property was explicitly set, documentation may describe a null value as meaning that default service settings apply. Confirm the behavior for your account rather than treating a missing value as a failure.

Enable SMB Multichannel Using Azure CLI

If the service-side property needs to be explicitly enabled for the selected account, use:

az storage account file-service-properties update \
  --resource-group <resource-group> \
  --account-name <storage-account> \
  --enable-smb-multichannel true

Apply changes first in a non-production environment or a controlled change window. Record the before-and-after setting and measured workload behavior.

Enable SMB Multichannel Using PowerShell

The following Azure PowerShell example retrieves the storage account and inspects its file service property:

$storageAccount = Get-AzStorageAccount `
  -ResourceGroupName "<resource-group>" `
  -Name "<storage-account>"

Get-AzStorageFileServiceProperty -StorageAccount $storageAccount

Enable SMB Multichannel explicitly where required:

Update-AzStorageFileServiceProperty `
  -StorageAccount $storageAccount `
  -EnableSmbMultichannel $true

Use placeholders deliberately and replace them with values from the intended subscription and resource group only after change review. Always verify the selected Azure context before changing a production storage account.

Verify from a Windows Client

First confirm whether the Windows SMB client has Multichannel enabled:

Get-SmbClientConfiguration | Select-Object EnableMultichannel

Inspect interfaces visible to SMB:

Get-SmbClientNetworkInterface

After connecting to the Azure file share and generating suitable I/O, inspect active multichannel connections:

Get-SmbMultichannelConnection

Verification requires an active workload. If no meaningful file I/O is taking place, the result may not demonstrate the performance behavior being assessed.

Troubleshooting

If expected channels or throughput do not appear, investigate the problem in layers:

1. Confirm that the file share is in a supported SSD configuration and that service-side SMB Multichannel is enabled or using the expected default.
2. Confirm that the client uses a supported, patched Windows configuration and that EnableMultichannel is true.
3. Validate DNS resolution and the actual network path, especially when private endpoints are used.
4. Check TCP 445 reachability and any firewall, network security group or forced-routing behavior.
5. Inspect client VM and network interface capability, including RSS visibility and available CPU/network performance.
6. Measure using representative file sizes and concurrency rather than a single small copy operation.
7. Compare observed performance with documented Azure Files limits and the storage account design.

Performance troubleshooting should collect evidence: share configuration, network path, client specifications, test method, throughput and relevant diagnostics. Without that evidence it is easy to attribute a bottleneck to the wrong platform layer.

Enterprise Architecture Considerations

In a governed Azure platform, file services should fit established patterns for identity, networking, private DNS, monitoring, backup and cost ownership. If Azure Files is offered as a reusable capability for product teams, the platform contract should state which tiers are supported, how private endpoints and DNS are created, how identity-based access is configured and how high-performance requirements are assessed.

For AVD or another shared platform, avoid assuming that one tuning setting solves all user-experience questions. Profile storage design, availability, authentication, backup, image operations and user concurrency all contribute to outcomes.

Treat SMB Multichannel as an optimization that can be enabled and validated within a well-designed file-service pattern. It is most credible when the decision is driven by measured workload need and verified after deployment.

Summary

Azure Files SMB Multichannel can improve throughput for supported Windows clients accessing SSD file shares by using multiple SMB connections. A sound implementation validates storage tier, client support, network and private DNS design, explicit configuration and observed performance. The former preview registration workflow is no longer the appropriate setup path.

Further Reading

• SMB file shares in Azure Files
• Improve SMB Azure file share performance
• Manage SMB Multichannel on Windows Server