When Azure Files resolves publicly despite a Private Endpoint

There is an old joke among admins: it’s always DNS.

This time it was DNS as well. Just not the DNS I was looking at.

When I decided to write more, I promised to share the “this should work, but somehow it doesn’t” moments. This is one of them.

The target architecture

We are trying to make more and more of our Azure Virtual Desktop (AVD) environments truly cloud-native. The target architecture is simple:

• Microsoft Entra joined session hosts
• Microsoft Entra Kerberos for access to the profile share
• Azure Files for the FSLogix profile containers
• Private Endpoints, with public network access on the storage account disabled
• Managed Identity
• no dependency on a traditional Active Directory for the session hosts

And of course, everything deployed with Terraform.

The infrastructure was in place, so I reached the stage where FSLogix gets configured.

Everything looked correct

I went through the usual list, in Azure and in Intune:

1. The Private Endpoint for the storage account existed.
2. The Private DNS zone for Azure Files, privatelink.file.core.windows.net, was configured.
3. The A record pointed to the private IP of the endpoint.
4. The zone was linked to the VNet of the session hosts.
5. The FSLogix configuration profile was properly deployed through Intune.

All green.

BUT FSLogix could not reach Azure Files over SMB on port 445.

Even more confusing: when the session host resolved the storage account name, it got a public Microsoft IP address instead of the address of the Private Endpoint.

At first, it looked like a Private DNS problem, or some other networking problem.

It wasn’t.

What was actually happening

To understand the problem, it helps to remember how name resolution for a Private Endpoint works.

FSLogix connects to the normal storage name, \\<account>.file.core.windows.net\<share>. It never uses the privatelink name directly. Once a Private Endpoint exists, the public DNS answer for that name is a CNAME to <account>.privatelink.file.core.windows.net. What happens next depends on who answers:

• Azure DNS, inside a VNet that is linked to the private zone, answers with the private IP of the endpoint.
• Every other resolver answers with the public IP of the storage service.

So the result does not depend on the Azure configuration alone. It depends on which resolver the session host actually asks.

In our case, the answer was the Zscaler client running on the session host. Zscaler was altering DNS and network traffic in a way that bypassed the expected Azure Private DNS resolution path. Instead of resolving through privatelink.file.core.windows.net to the Private Endpoint, the storage name kept resolving to the public Microsoft endpoint. And because public network access on the storage account was disabled, the connection naturally failed. Exactly as the storage account was configured to behave.

From Azure’s point of view, nothing was broken. The traffic simply never took the path Azure expected.

How to check it on the session host

If you end up in the same situation, a few commands on the session host tell you a lot within a minute:

# What does the session host actually get?
Resolve-DnsName <account>.file.core.windows.net

# What does Azure DNS answer when asked directly?
Resolve-DnsName <account>.file.core.windows.net -Server 168.63.129.16

# Does SMB reach the storage account?
Test-NetConnection <account>.file.core.windows.net -Port 445

# Which DNS servers does Windows use, and do any rules redirect specific names?
Get-DnsClientServerAddress
Get-DnsClientNrptPolicy

What you want to see is the CNAME to <account>.privatelink.file.core.windows.net and, at the end of the chain, the private IP of your endpoint.

• The first query returns a public IP, the second one the private IP. Azure Private DNS is fine. The question is what the host asks instead: a custom DNS server configured on the VNet, or an agent on the host itself.
• Both return a public IP. Check the Azure side first: the VNet link, the record and the DNS servers configured on the VNet. If all of that is correct, compare with a session host where the agent is not running.
• DNS is correct, but port 445 still fails. Look at the network path: network security groups, routing and, again, any agent that tunnels traffic.

The fix

Once the appropriate Zscaler exclusions were applied, DNS immediately started resolving to the private endpoint IP and TCP 445 worked as expected. FSLogix was happy, and so was I.

Which exclusions you need depends on how Zscaler is set up in your organisation, so I won’t pretend there is one list that fits everyone. The goal is the same everywhere:

• DNS queries for the storage account are answered inside the VNet, so the privatelink zone can do its job.
• Traffic to the Private Endpoint stays on the private path and is not sent anywhere else.

Talk to whoever owns Zscaler early. Often that is a different team from the one building AVD, and that conversation can take longer than the configuration itself.

What I take from it

If the Private Endpoint and Private DNS configuration look correct, but the client still resolves a public endpoint, do not assume Azure DNS is broken. Check the endpoint itself, in this case the session host. Zscaler, VPN clients, DNS filtering tools and other security agents can completely change the effective DNS and network path.

With cloud-native AVD this is easy to miss, because a session host is not only a VM in a subnet. It is also a managed endpoint, and it can carry the same security agents as any other endpoint. So it belongs on the checklist: before you blame Private DNS, check what runs on the session host and how it handles DNS.

Sometimes the cloud configuration is correct. The problem is what happens before the traffic ever reaches it.

Hopefully, this saves someone a few hours of troubleshooting. Questions? Poke me with a DM on LinkedIn.