Share via

FSLogix Error 1265 – Profile Container Not Mounting | Azure Files Kerberos Auth Failing on AVD (AADDS)

Thamizh Selvi L 0 Reputation points
2026-06-11T08:44:17.17+00:00

Issue:

FSLogix is failing with Event ID 1265 on our AVD session hosts. Users are falling back to local non-persistent profiles instead of loading their VHD profile containers from Azure Files.

After investigation, we identified the root cause:

Our internal DNS server cannot resolve kerberos.microsoftonline.com, which is required for Entra ID Kerberos authentication to the Azure File Share. The DNS query returns NXDOMAIN because there is no forwarder configured for microsoftonline.com.

Steps already taken:

  • FSLogix installed on all VMs
  • Registry keys confirmed present (Enabled=1, VHDLocations set correctly)
  • Azure File Share has AADDS Kerberos authentication enabled
  • NTFS and RBAC permissions set on the file share
  • VMs are domain-joined

Questions:

  1. Is adding a conditional forwarder for microsoftonline.com → 168.63.129.16 the officially recommended approach for AADDS + FSLogix + Azure Files setups?
  2. Are there other endpoints that FSLogix / Entra Kerberos requires that we should also whitelist in DNS?
  3. Should the AADDS DNS servers themselves (not just our internal DNS) have this forwarder configured?
Azure Virtual Desktop
Azure Virtual Desktop

A Microsoft desktop and app virtualization service that runs on Azure. Previously known as Windows Virtual Desktop.

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Himanshu Shekhar 6,710 Reputation points Microsoft External Staff Moderator
    2026-06-11T09:02:43.19+00:00

    Thamizh Selvi L

    1. Is a conditional forwarder for microsoftonline.com → 168.63.129.16 the recommended approach?

    No. 168.63.129.16 (Azure's virtual DNS IP) is the recommended forwarder target only for resolving your storage account's private endpoint FQDN (<storageaccount>.file.core.windows.net) so it resolves to the private IP — that's the official DNS forwarding scenario. It is not intended or recommended for microsoftonline.com. citeturn4search66 Forwarding microsoftonline.com to 168.63.129.16 won't fix Kerberos auth and may have side effects.

    1. Other endpoints to allow in DNS / firewall?

    The connectivity dependencies depend on the identity source:

    AADDS model: Session hosts need network line-of-sight (DNS + ports) to the AADDS managed domain controllers, plus resolution of the Azure Files FQDN to the correct (public or private) endpoint. citeturn4search58

    Entra Kerberos model: Outbound HTTPS (443) to login.microsoftonline.com must be reachable; Conditional Access / MFA must not block the storage account app path; and CloudKerberosTicketRetrievalEnabled must be set on the hosts. citeturn4search64turn4search62

    1. Should AADDS DNS servers have this forwarder?

    For an AADDS setup, the relevant requirement is that your session hosts use DNS that can resolve the managed domain and the Azure Files FQDN, not a microsoftonline.com forwarder. The standard private-endpoint forwarding (core.windows.net > 168.63.129.16) is what's documented. citeturn4search66

    Recommended next diagnostic steps

    To pin the real cause of Event ID 1265:

    1. Confirm the actual identity source on the storage account (AADDS vs Entra Kerberos) this drives everything.
    2. Test name resolution + reachability of the correct endpoint for your model (managed-domain DCs for AADDS, or login.microsoftonline.com:443 for Entra Kerberos).
    3. Capture the specific sub-error / status code in the FSLogix Profile operational log and fslogix_event.txt (Event 1265 is generic; the accompanying error code identifies the real failure).

    For Entra Kerberos hosts, validate the cloud TGT with klist cloud_debug / dsregcmd /status and confirm the storage app registration has admin consent. citeturn4search62

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.