5. July 2026

Accessing Backend File Shares from AVD Applications

Article written by Donny in the category Uncategorized

When designing Azure Virtual Desktop, it’s easy to focus on the visible parts of the platform that we’ve discussed in the previous articles.

Host pools. Session hosts. Images. Applications. Profiles. Security controls. Scaling plans.

But one of the most important design areas often sits behind the application itself:

How does the application access the file shares it depends on?

For many organisations, applications running inside AVD still need to read and write data from backend SMB file shares. These might be traditional on-premises Windows file servers, Azure Files shares, profile containers, departmental shares, application data locations, mapped drives, or old UNC paths that have existed quietly in the background for years.

And this is where AVD design can quickly become more complicated than expected.

Because accessing a file share from an AVD session host is not just a storage question.

It’s an identity question. It’s a permissions question. It’s a Kerberos question. It’s a DNS question. It’s a network routing question. And very often, it’s a legacy application question.

The common scenarios

In real AVD environments, file share access usually falls into a few common patterns.

Applications need access to on-premises SMB shares

This is common during Citrix to AVD migrations or wider desktop modernisation projects.

The application may still expect to access data from:

\\fileserver\apps
\\fileserver\departments
\\domain.local\dfsroot
Mapped drives such as S:\, H:\, or P:\

In this scenario, the AVD session host needs to be able to resolve the file server name, route to the file server, authenticate the user or service account, and apply the correct permissions.

That usually means checking:

Can the session host resolve the internal DNS name?
Can it reach the file server over SMB?
Can it reach a domain controller if Kerberos is required?
Is the user identity valid in the domain that owns the share?
Are the share permissions and NTFS permissions aligned?
Does the application use the signed-in user, a service account, or stored credentials?

If any one of those is wrong, the application may launch perfectly but fail the moment it tries to open a file.

Applications need access to Azure Files

Azure Files is often used as a managed SMB file share service in Azure. It can reduce the need to run and manage traditional file servers, and it can be useful for application shares, departmental shares, lift-and-shift workloads, and FSLogix profile storage.

However, Azure Files still needs proper design. The important question is not just:

“Can I create an Azure file share?”

The better question is:

“Which identity model will be used to access this Azure file share, and how will permissions be enforced?”

Azure Files can support identity-based authentication, which allows access to be controlled at the share level, file level and the directory level, similar to a traditional Windows file server model.

That is powerful, but it means the identity source must be chosen carefully.

Overview - Azure Files Identity-Based Authentication | Microsoft Learn

User profiles are stored in Azure Files

FSLogix profile containers are one of the most common uses of Azure Files in AVD.

In this design, the user signs in to AVD, FSLogix attaches their profile container from a file share, and the user gets a consistent profile experience across session hosts.

If this is not designed correctly, users may experience:

Slow logons
Temporary profiles
Profile locking
Access denied errors
Poor application performance
Inconsistent settings
Failed profile container attachment

This is why profile storage is not just a storage decision. It needs to be designed alongside identity, permissions, Kerberos, network routing, DNS, performance, and operational support.

I wont go into profile access too much here as its already been discussed in my “AVD Application and Profile Strategy: Where User Experience Is Won or Lost” article ( shameless plug so you go and read the previous articles!).

Legacy apps expect mapped drives or UNC paths

Many legacy applications were never designed with cloud-hosted desktops in mind.

Some expect a mapped drive. Some expect a hardcoded UNC path. Some expect the user’s home drive. Some expect a service account. Some write configuration files into shared folders. Some break if the path changes.

Before moving these applications into AVD, you need to understand how they access data today.

A simple application discovery question such as: “Where does this application store or retrieve files?” can uncover a huge amount of hidden dependency.

The key design questions

For every application that needs backend file share access, I would ask these questions before finalising the AVD design.

1. What is the session host joined to?

Is the AVD session host:

Active Directory domain joined?
Microsoft Entra hybrid joined?
Microsoft Entra joined only?

This matters because the join type influences how the session host authenticates to backend resources.

A domain-joined or hybrid-joined session host may be a better fit where applications still depend heavily on traditional AD DS, Kerberos, NTLM, Group Policy, DFS namespaces, and on-premises file servers.

A Microsoft Entra joined session host may be a better fit for modern AVD designs, especially where backend dependencies have been reduced or where Azure Files with Microsoft Entra Kerberos is being used.

Neither model is automatically right or wrong. The right answer depends on the applications, file shares, identity model, and operational requirements.

2. Where is the file share hosted?

The file share could be:

An on-premises Windows file server
A DFS namespace
Azure Files
Azure NetApp Files
A file server VM in Azure
A third-party storage platform
A legacy NAS device

Each option has different implications for authentication, permissions, routing, latency, resilience, backup, monitoring, and support.

For example, an on-premises file share may require VPN or ExpressRoute connectivity from Azure back to the datacentre. Azure Files may require private endpoints, private DNS, and identity-based access configuration. A file server VM in Azure may still need domain controller connectivity and traditional Windows Server management.

3. Which identity is used to access the share?

This is one of the most important design questions. Is the share accessed using:

The signed-in user identity?
A domain user account?
A cloud-only Microsoft Entra user?
A synced hybrid identity?
A service account?
A managed identity?
A machine account?
Stored credentials?

This needs to be understood before the design is agreed.

A user opening a file from Word is very different from a legacy application service writing files using a service account. FSLogix accessing a profile container is different again.

The identity used by the application determines how authentication and authorisation need to be configured.

Using Endpoint Privilege Management can be used to elevate user permissions when apps need admin rights to run. This can also be viewed in my “Using Endpoint Privilege Management with Azure Virtual Desktop: Secure Elevation Without Local Admin Rights” article. (Two shameless plugs in one article!)

4. Are share-level and NTFS permissions aligned?

This is a classic gotcha.

Access to a file share normally depends on both:

Share-level permissions
Directory and file-level permissions

With Azure Files identity-based access, this same principle still applies. Assigning share-level access is not enough on its own. The user or group still needs the correct directory and file-level permissions.

A good design should define:

Who can access the share?
Who can read, write or modify?
Who can change permissions?
Which admin groups have elevated access?
How are permissions reviewed?
How are permissions migrated from existing file servers?

Permissions shouldn’t be copied blindly from an old environment without review. AVD migrations are a good opportunity to clean up years of inherited access that nobody wants to explain in a security review.

5. Is Kerberos required?

For many SMB scenarios, Kerberos is still central.

Traditional on-premises file server access often relies on AD DS and Kerberos. Azure Files identity-based authentication also uses Kerberos when using supported identity sources.

This becomes especially important when you are choosing between:

AD DS authentication for Azure Files
Microsoft Entra Domain Services authentication
Microsoft Entra Kerberos
Storage account key access

Storage account keys may be useful for some administrative or isolated use cases, but they shouldn’t be the default design for user access. Identity-based access gives a much better security and operational model.

6. Does DNS resolve correctly from the session host subnet?

This one sounds boring. It’s not.

A large number of file access issues come down to DNS. The session host needs to resolve the correct name to the correct endpoint. For on-premises file servers, that may mean resolving internal AD DNS zones across VPN or ExpressRoute.

For Azure Files with private endpoints, that may mean ensuring the storage account file endpoint resolves to the private endpoint IP address from the session host subnet.

If DNS resolution sends the session host to the wrong place, authentication and routing troubleshooting becomes a rabbit hole. DNS should be tested before users are onboarded.

As a wise man (and ALL IT admins have said) “Its always DNS”

7. Does traffic route through the correct path?

Even if identity and permissions are correct, the session host still needs network connectivity to the file share.

That might involve:

Hub and spoke routing
Azure Firewall
Network virtual appliances
NSGs
Private endpoints
Private DNS zones
VPN
ExpressRoute
User-defined routes
SMB over TCP 445
Firewall inspection policies

For on-premises shares, the question is whether the session host can reach the file server and domain controllers.

For Azure Files, the question is whether the session host can reach the correct Azure Files endpoint, preferably through a private endpoint for production environments where public exposure is not desired.

This should be validated using real tests from the session host subnet, not assumed from a diagram.

Azure Files and identity-based access

Azure Files can support identity-based authentication for SMB access. This allows organisations to use a permissions model that feels closer to traditional Windows file services, with permissions applied at the share level and at the directory/file level.

The identity source can be one of the following:

On-premises Active Directory Domain Services
Microsoft Entra Domain Services
Microsoft Entra Kerberos

The important design point is that only one identity source can be enabled per storage account for Azure Files identity-based SMB authentication.

That means this is not a casual setting to click through during deployment.

It’s an architectural decision.

If a storage account is configured for AD DS authentication and you later decide that Microsoft Entra Kerberos is the better model, you need to understand the impact before switching. Changing the identity source affects file access for the shares in that storage account.

For AVD environments, I would normally decide the Azure Files identity model during the design phase, not during build.

Microsoft Entra Kerberos and Entra-only access

One of the most important changes in this area is the ability to use Microsoft Entra Kerberos for Azure Files in supported scenarios. We’ve discussed this previously but it’s a big deal here as it will have an impact on how the session hosts are deployed and how you access file shares.

This is significant because it can allow Microsoft Entra joined AVD session hosts and Microsoft Entra identities to access Azure file shares over SMB without requiring traditional domain controller line-of-sight for the session hosts.

For cloud-only environments, this opens up a much cleaner design pattern:

Users are created in Microsoft Entra ID
Session hosts are Microsoft Entra joined
Azure Files uses Microsoft Entra Kerberos
Users access SMB file shares using identity-based authentication
FSLogix profiles can be stored on Azure Files
No traditional AD DS domain controller is required for that Azure Files access pattern

That is a big shift from older AVD designs where Active Directory was often assumed to be mandatory.

However, this needs careful design. You still need to configure:

The correct Azure Files identity source
Share-level permissions
Directory and file-level permissions
Microsoft Entra Kerberos settings
Client/session host configuration to retrieve Kerberos tickets
Conditional Access considerations
Private endpoint and DNS configuration
Operational processes for permission changes
Supportability for the Azure region and identity scenario being used

This shouldn’t be treated as “AVD without AD is always simple.”

It’s more accurate to say:

“AVD can now be designed without traditional domain controllers for some Azure Files access scenarios, but the identity, permissions, and network design still need to be deliberate.”

Microsoft Entra Kerberos Authentication for Azure Files | Microsoft Learn

On-premises SMB shares still need traditional thinking

Not every file share should immediately move to Azure Files.

Some applications still need on-premises data. Some file services are deeply integrated with legacy systems. Some applications rely on DFS, domain-based permissions, service accounts, or direct access to nearby application servers.

In those scenarios, AVD can still access on-premises SMB shares, but the design needs to include:

Connectivity from Azure to on-premises
DNS resolution for internal names
Authentication to the relevant AD domain
Domain controller availability
File server availability
Latency expectations
Firewall rules
SMB inspection or blocking policies
Backup and recovery
Monitoring and support ownership

A poor network path to a file share can make an otherwise well-sized AVD environment feel slow.

Practical design approach

When designing backend file share access for AVD applications, I would use a simple approach.

Step 1: Discover the file dependencies

For each application, identify:

Which shares are used
Whether paths are mapped drives or UNC paths
Whether the paths are hardcoded
Whether the application uses the user identity or a service account
Whether the data is read-only or read/write
Whether the application stores temporary, configuration, or transactional data
Whether the share is business critical
Whether the share has performance or latency requirements

Step 2: Map the identity flow

Document how the user or application authenticates. This should include:

User sign-in to AVD
Session host join type
Identity used by the application
Identity source for the file share
Kerberos requirements
Share and NTFS permission model

This is where many issues are found before deployment.

Step 3: Validate DNS and routing

From the session host subnet, test:

Name resolution
SMB connectivity
Private endpoint resolution
Firewall rules
Routing paths
Connectivity to domain controllers if required
Access from each relevant host pool

Do not only test from an admin machine. Test from where the workload actually runs.

Step 4: Design the permissions model

Define the permission structure before migration.

For Azure Files, remember that share-level permissions and directory/file-level permissions both matter.

For on-premises shares, review whether existing ACLs are still appropriate.

For FSLogix, use a permissions model that allows users to access their own profile containers while allowing administrators to manage the platform safely.

Step 5: Pilot with real applications

File share access should be tested with real applications, not just net use.

A mapped drive test might pass, but the application may still fail because it expects a specific path, service account, working directory, lock file, or write behaviour.

Use real user personas and real application workflows during testing.

Common risks

The most common risks I see in this area are:

Assuming Entra ID sign-in to AVD automatically means file share access will work
Forgetting that legacy apps may use service accounts or hardcoded paths
Misaligning share-level and NTFS permissions
Choosing the wrong Azure Files identity source
Not testing Kerberos properly
Not configuring DNS for private endpoints
Routing SMB traffic through a firewall path that blocks or inspects it incorrectly
Using storage account keys where identity-based access would be better
Moving profiles to Azure Files without validating performance and permissions
Not documenting who owns file share support after go-live

The design principle

The key principle is simple:

AVD application access to file shares should be designed, not discovered during testing.

By the time users start logging into AVD, you should already know:

Which applications need file shares
Where those shares are hosted
Which identities are used
How Kerberos works
How permissions are applied
How DNS resolves
How traffic routes
How performance has been tested
Who supports the service

When this is done properly, AVD applications can access backend data securely and reliably, whether that data lives on-premises, in Azure Files, or across a hybrid model.

When it’s not done properly, the AVD platform may look healthy while the user experience quietly falls apart.

…and finally

The real lesson is, AVD is not just a desktop platform, it’s part of a wider application, identity, data, and network architecture. Backend file share access is where all of those areas meet.

A couple of source-backed points worth keeping near the article when you publish: Azure Files private endpoints place the storage endpoint on a private IP in the VNet and can be reached from on-premises over VPN or ExpressRoute; SMB needs TCP 445 open; and Azure Files share-level permissions do not replace directory/file-level ACLs.