Map X drive from File Server (which is a domain-joined VM) to AVD (entra-joined AVD)

Hi Luke,

Thanks for the detailed write-up this is a pretty common scenario and completely doable, but there are a couple of moving parts worth understanding before jumping into the config.

The core challenge here is the identity gap: your AVD session hosts are Entra-joined, but your file server is domain-joined (AD DS). These two worlds don't talk to each other natively unless your users are hybrid identities — meaning their on-prem AD accounts are synced to Entra ID via Microsoft Entra Connect Sync or Cloud Sync. If that's already in place, you're in good shape.

Here's the approach I'd recommend:

1. Confirm hybrid identity is set up

Make sure your users exist in both on-prem AD and Entra ID (synced, not cloud-only). This is the foundation everything else depends on.

2. Enable Kerberos ticket retrieval on AVD session hosts

Entra-joined machines need a policy to fetch a Kerberos ticket at logon so they can authenticate against domain resources like your file server. Deploy this via Intune Settings Catalog (not OMA-URI — that doesn't work reliably on multisession AVD hosts):

Administrative Templates → System → Kerberos → "Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon" → Enabled

https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-kerberos

3. Verify network line-of-sight

Your AVD VNet needs to reach the file server VM on TCP 445 (SMB) and TCP 88 (Kerberos). If they're in the same VNet or peered VNets, this is usually fine — just double-check your NSG rules aren't blocking those ports.

4. Map the drive via a PowerShell logon script

Once Kerberos is flowing, you can map the X: drive using a user-context PowerShell script deployed through Intune. Key settings when uploading the script:

• Run script using logged-on credentials: Yes
• Run in 64-bit PowerShell: Yes

A basic example:

$share = "\\YourFileServer\SharedData"

if (-not (Get-PSDrive -Name 'X' -ErrorAction SilentlyContinue)) {

    New-PSDrive -Name 'X' -PSProvider FileSystem -Root $share -Persist -Scope Global

}

If you hit timing issues at logon (Kerberos ticket not ready yet), add a short retry loop or a Start-Sleep before the mapping attempt.

5. Check share and NTFS permissions on the file server

Make sure the AD security group your users belong to has both SMB share permissions and appropriate NTFS permissions on the file server side. This is easy to miss when testing.

One thing to watch out for: if you have a Conditional Access policy enforcing MFA on all cloud apps, it can interfere with Kerberos ticket retrieval. You may need to exclude the Azure Storage app from that policy.

https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable?tabs=azure-portal%2Cintune

Also, if you're using FSLogix for user profiles, make sure you set this registry key on the session hosts so credential keys load correctly with the profile:

reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

https://learn.microsoft.com/en-us/azure/virtual-desktop/azure-ad-joined-session-hosts

Thanks,
Manish.

Entra‑only AVD has no Kerberos path to an AD‑joined file server (Azure AD Kerberos works only with Azure Files), so the practical fix is to hybrid‑join the host and run a small net use X: \filesrv\share at logon.