Lesson 08 — Azure Files & Azure File Sync

Domain 2 — Storage AZ-104: 15–20% ~25 min Prereq: Lesson 07 — Blob Storage

Why Azure Files Deserves Serious Attention

Every enterprise has legacy workloads built around shared file systems — SMB shares, home drives, departmental file servers, application configuration mounts. Azure Files is Microsoft's answer to lifting those workloads to the cloud without re-architecting them. It is not just "storage you can mount"; it is a fully managed file service with enterprise-grade identity integration, snapshot capabilities, and a hybrid synchronisation agent (Azure File Sync) that makes on-premises-to-cloud migration genuinely practical.

For the AZ-104 exam, Azure Files is tested primarily on: authentication models (especially the differences between AD DS, Entra Domain Services, and Entra Kerberos), protocol requirements (SMB vs NFS), Azure File Sync architecture, and the gotchas around large file shares and port 445. Get these right and this section is easy marks.

Azure Files Overview & Protocol Support

Azure Files provides fully managed cloud file shares that are accessible via industry-standard protocols. You access them the same way you would a traditional file server — with a drive letter on Windows or a mount point on Linux — but all the infrastructure is managed by Azure.

ProtocolSupported VersionsOS SupportIdentity AuthNotes
SMB 2.1, 3.0, 3.1.1 Windows & Linux Yes (AD DS, Entra DS, Entra Kerberos) Requires port 445 outbound. SMB 3.0+ adds encryption in transit.
NFS 4.1 Linux only No (network-level only) Premium tier only. No public endpoint — requires VNet integration (private endpoint or service endpoint). HNS must be disabled.
REST API — Any Storage account key / SAS Used for management operations, AzCopy, Azure portal. Not a mount protocol.
NFS 4.1 requirements — exam trap NFS 4.1 is Linux-only and requires a Premium File Shares storage account. It does not support the public endpoint — you must use a private endpoint or VNet service endpoint. Hierarchical namespace (HNS) must be disabled on the storage account (NFS on Azure Files is not ADLS Gen2). There is no identity-based authentication for NFS shares in Azure Files.

Storage Account Requirements

The storage account type you choose determines the performance tier available for your Azure file shares. This is a critical architecture decision because changing tier later is disruptive.

Account TypePerformance TierMediaUse CaseMax Share Size
Standard GPv2 Standard HDD (magnetic) General purpose, less latency-sensitive workloads 5 TiB by default; 100 TiB with large file shares enabled
Premium File Shares Premium SSD (NVMe) Low-latency, high-IOPS workloads; NFS 4.1 100 TiB

Large File Shares on Standard GPv2

By default, Standard GPv2 file shares are capped at 5 TiB. You can enable large file shares at the storage account level to increase this to 100 TiB.

Large file shares enablement is irreversible Once you enable large file shares on a Standard GPv2 storage account, you cannot reverse it. Additionally, once enabled, you can no longer use geo-redundant storage (GRS or GZRS) on that account — it is limited to LRS or ZRS. Plan this carefully before enabling. If you need both large shares and geo-redundancy, this combination is not supported on Standard tier.

Share Quotas: Soft vs. Hard Limits

Each Azure file share has a configurable quota. Understand the difference between how quotas work for billing vs. enforcement:

  • Soft limit (Standard tier): The quota is a warning threshold. When reached, you receive alerts, but writes are not blocked. You are billed for actual usage.
  • Hard limit (Premium tier): The quota is enforced — once the share reaches the quota size, writes are refused. You are billed for the provisioned quota, not actual usage.

Authentication for Azure Files (SMB)

Azure Files supports four authentication methods for SMB. Choosing the wrong one for your environment is a common architectural mistake — the right answer depends on your identity topology.

Authentication MethodIdentity SourceBest ForRequires
Storage Account Key None (key-based) Emergency access, service accounts with no AD Nothing extra
On-premises AD DS (Kerberos) On-prem Active Directory Enterprises with on-prem AD and domain-joined machines Storage account joined to on-prem AD domain; line-of-sight or DC sync
Microsoft Entra Domain Services Azure-managed AD (cloud) Cloud-only environments; Azure VMs not joined to on-prem AD Entra DS tenant deployed; VMs domain-joined to Entra DS
Microsoft Entra Kerberos Microsoft Entra ID (hybrid/cloud-native) Hybrid-joined or Entra-joined Windows 10/11 devices (newest, preferred) Windows 10 21H1+ or Windows 11; Entra ID; no on-prem AD required
Storage account key = root access The storage account key grants full, unrestricted access to all data in the storage account. It is the equivalent of a root password. Never use it as a day-to-day authentication mechanism for Azure Files. Rotate keys regularly, store them in Key Vault, and use identity-based authentication wherever possible.

Microsoft Entra Kerberos — The Modern Choice

Microsoft Entra Kerberos is the newest and preferred authentication path for Azure Files. It works with:

  • Hybrid Azure AD-joined devices (joined to both on-prem AD and Entra ID)
  • Entra ID-joined devices (cloud-native, no on-prem AD needed)
  • It does not require deploying or managing Entra Domain Services or maintaining on-prem AD connectivity

The key technical distinction: Entra Kerberos uses Entra ID identities and issues Kerberos tickets via Entra ID itself, eliminating the dependency on a traditional domain controller for the ticket-granting process.

Share-Level Permissions vs. File/Directory ACLs

Azure Files uses a two-layer permissions model when identity-based authentication is configured. Both layers must grant access for a user to read or write a file.

Share-Level Permissions (RBAC — Azure Resource Manager plane) └─ Controls who can access the share at all └─ Three built-in roles: Storage File Data SMB Share Reader (read-only) Storage File Data SMB Share Contributor (read/write/delete) Storage File Data SMB Share Elevated Contributor (modify ACLs) File/Directory ACLs (NTFS-style — file system plane) └─ Controls per-file and per-directory permissions └─ Set via Windows File Explorer, icacls, or PowerShell └─ Standard Windows NTFS ACE entries: Full Control, Modify, Read, Write, Execute
Both layers evaluated independently A user must pass BOTH the share-level RBAC check AND the NTFS ACL check to access a file. Being a Storage File Data SMB Share Contributor does not override a Deny ACL on a specific folder. Conversely, having Full Control NTFS ACLs on a file is irrelevant if share-level access has not been granted. This is identical in concept to traditional Windows SMB share permissions + NTFS ACLs.

Mounting Azure File Shares

Windows

Azure file shares are mounted on Windows using standard net use commands or the persistent drive mapping via File Explorer. The Azure portal provides a ready-made PowerShell script under each share's "Connect" blade.

# Mount using storage account key (for testing — use identity auth in production)
net use Z: \\storageaccountname.file.core.windows.net\sharename /user:Azure\storageaccountname storageaccountkey

# Persistent mount — survives reboot
cmdkey /add:storageaccountname.file.core.windows.net /user:Azure\storageaccountname /pass:storageaccountkey
net use Z: \\storageaccountname.file.core.windows.net\sharename /persistent:yes

Linux

Linux mounts use the cifs-utils package to mount SMB shares. NFS 4.1 shares use standard NFS mount tooling.

# Install cifs-utils
sudo apt-get install cifs-utils

# Mount SMB share
sudo mount -t cifs //storageaccountname.file.core.windows.net/sharename /mnt/azurefiles \
  -o vers=3.0,username=storageaccountname,password=<key>,dir_mode=0777,file_mode=0777
Port 445 — the enterprise blocker SMB traffic uses TCP port 445 outbound. Many ISPs and corporate firewalls block this port as a legacy security measure (MS17-010 / WannaCry era). If you cannot open port 445, you cannot directly mount Azure Files from on-premises. The architectural solution is Azure File Sync, which caches the share locally on a Windows Server — the server makes outbound HTTPS (port 443) connections to Azure, eliminating the port 445 requirement from the network boundary.

Azure File Sync

Azure File Sync is a service that caches Azure file shares on one or more Windows Server machines — either on-premises or in Azure VMs. It solves the port 445 problem, enables multi-site file sharing, and provides a migration path for retiring physical file servers while keeping users' drive-letter access.

Architecture Components

Storage Sync Service (Azure resource — top-level AFS resource) └─ Sync Group (defines what stays in sync together) ├─ Cloud Endpoint (exactly ONE — the Azure file share) └─ Server Endpoints (one or more — paths on registered Windows Servers) e.g. D:\Data on FILESERVER-LONDON e.g. E:\Shares on FILESERVER-NEWYORK └─ Azure File Sync Agent (installed on each Windows Server)
ComponentRoleCardinality per Sync Group
Storage Sync Service Top-level Azure resource. Registers servers and owns sync groups. 1 per deployment (can span multiple sync groups)
Sync Group Defines a synchronisation topology — which servers sync with which cloud share. Multiple per Storage Sync Service
Cloud Endpoint The Azure file share that is the source of truth for the sync group. Exactly 1 per sync group
Server Endpoint A path on a registered Windows Server that participates in sync. Multiple per sync group
Registered Server A Windows Server (2012 R2+) with the AFS agent installed and registered. Multiple per Storage Sync Service

Synchronisation Behaviour

Sync is bidirectional. Changes made in Azure (directly to the cloud endpoint) propagate to all server endpoints in the sync group. Changes made on any server endpoint propagate to the cloud endpoint and from there to all other server endpoints. This makes Azure File Sync a practical replacement for DFS-R (Distributed File System Replication) in multi-site scenarios.

Conflict resolution When the same file is modified on two server endpoints simultaneously (before sync converges), Azure File Sync creates a conflict file. The most recently modified version becomes the canonical file; the other is renamed with a conflict suffix. This is similar to OneDrive conflict behaviour.

Cloud Tiering

Cloud tiering is one of the most powerful — and most misunderstood — features of Azure File Sync. When enabled on a server endpoint, files that have not been accessed recently are replaced on the local server with a reparse point (a tiny pointer file). The actual file data remains in the Azure file share. When a user or application opens the tiered file, the Azure File Sync agent transparently recalls it from Azure on demand.

Tiering PolicyWhat it controlsExample
Volume free space policy Ensures the server volume maintains a minimum percentage of free space. Azure File Sync tiers oldest files first to maintain this free space percentage. Keep 20% free on D: — when D: hits 80% capacity, start tiering
Date policy Files not accessed within N days are tiered, regardless of disk space. Tier any file not opened in the last 30 days
Cloud tiering and backups Standard backup agents (VSS-based, file-level) will attempt to recall tiered files during backup, potentially pulling gigabytes from Azure over your WAN link. Configure backup policies to use VSS-aware backup or use Azure Backup directly for Azure Files. Also note: cloud tiering requires at least a /26 subnet free from VSS compatibility concerns.

Pre-Seeding with Robocopy

When migrating large datasets to Azure File Sync, uploading all data from scratch over the internet is impractical. The recommended approach is pre-seeding:

  1. Use Robocopy (or AzCopy) to copy data directly to the Azure file share — often via ExpressRoute or Azure Data Box for large datasets.
  2. After data is in Azure, create the sync group and add server endpoints.
  3. Azure File Sync performs a namespace reconciliation — it matches what's on the server against what's in Azure and syncs only the differences. This is far faster than re-uploading everything.

Snapshots and Azure Backup for Azure Files

Share Snapshots

Azure file shares support point-in-time share snapshots. A snapshot captures the state of the entire file share at the moment it is taken. Snapshots are incremental — only the changes since the last snapshot are stored — but from the user's perspective each snapshot appears as a full copy.

  • Snapshots are read-only and are stored within the same storage account as the file share.
  • You can restore individual files from a snapshot (via the "Previous Versions" tab in Windows, or via portal/CLI) or restore the entire share.
  • Snapshots do not protect against accidental deletion of the storage account itself — that requires soft delete or Azure Backup.
  • Maximum 200 snapshots per share.

Azure Backup for Azure Files

Azure Backup integrates with Azure Files to create scheduled snapshots via a Recovery Services Vault. This provides:

  • Policy-driven snapshot schedules (daily, weekly, monthly, yearly retention)
  • Centralised management across all file shares in a subscription
  • Integration with soft delete — deleted snapshots are retained for a configurable period before being permanently removed
  • Instant restore — individual files can be restored in seconds from any snapshot
Soft delete for Azure Files Soft delete, when enabled on a storage account, retains deleted file shares and their snapshots for a configurable period (1–365 days). This protects against accidental deletion by administrators. Soft delete is separate from snapshot retention — enable both for a defence-in-depth backup posture.

Check Your Understanding

Click any option to see immediate feedback. Answers represent correct behaviour in a real Azure environment.

1. Your organisation cannot open TCP port 445 outbound from the corporate network to the internet. You need on-premises users to access an Azure file share using their normal drive-letter mapping. What is the correct architectural solution?

Azure File Sync is the correct solution here. The sync agent on the Windows Server connects outbound to Azure on HTTPS (port 443), which is universally available. Users map a drive to the local Windows Server path — they never connect directly to Azure on port 445. ExpressRoute and VPN are valid for direct mount scenarios but both still require port 445 to be open at the SMB endpoint level, and neither bypasses the port 445 requirement from the client to the file share endpoint.

2. Your organisation is deploying cloud-native Windows 11 devices that are Entra ID-joined only (no on-premises AD). You want users to authenticate to Azure Files using their Entra ID credentials (Kerberos). Which authentication method should you configure?

Microsoft Entra Kerberos is the correct answer. It was specifically designed for this scenario: Entra ID-joined (cloud-native) and hybrid-joined Windows 10/11 devices accessing Azure Files using their Entra ID identities, without requiring on-premises AD DS or Entra Domain Services. NFS 4.1 is Linux-only and has no identity-based authentication. Storage account keys provide no per-user identity context.

3. A Windows Server participating in Azure File Sync has cloud tiering enabled. A user opens a file that has been tiered. What happens on the server?

Cloud tiering replaces file content with a reparse point — a tiny placeholder that looks like the original file (same name, size metadata, timestamps). When a user or application opens the tiered file, the Azure File Sync agent intercepts the I/O request via a filter driver and transparently recalls the file data from the Azure file share. The recall is transparent to the application — it just sees a brief delay during opening. No manual steps are required.

4. You need to replicate a single Azure file share to three Windows Server locations in different offices, so that all three offices can read and write the same files. How does Azure File Sync handle this topology?

This is the correct multi-site topology for Azure File Sync. One sync group contains one cloud endpoint (the Azure file share, which acts as the hub) and multiple server endpoints — one per Windows Server location. Sync is bidirectional: writes at any server endpoint flow to the cloud endpoint and then propagate to all other server endpoints. This makes Azure File Sync a modern replacement for DFS-R in multi-site file replication scenarios.

5. You need to store files larger than 5 TiB in an Azure Files standard (HDD) share. You enable large file shares on the storage account. What constraint must you accept?

Correct. Large file shares must be explicitly enabled at the storage account level on Standard GPv2, and this action is irreversible — you cannot downgrade. The critical trade-off is that GRS and GZRS become unavailable after enablement; only LRS and ZRS remain as redundancy options. If your workload requires both large shares and geographic redundancy, use a Premium File Shares account (which supports 100 TiB natively without this restriction, though Premium only supports LRS and ZRS).

6. A user is a member of the Storage File Data SMB Share Contributor RBAC role on an Azure file share. However, the user reports they cannot write to a specific folder within the share. Assuming the share is using AD DS Kerberos authentication, what is the most likely cause?

Both layers are evaluated independently. The Storage File Data SMB Share Contributor role grants share-level access (allows entry to the share at all), but NTFS ACLs on individual files and directories are also enforced by Azure Files. If a Deny ACL — or simply a missing Allow ACE — exists on the target folder for that user or group, the write will be blocked even though share-level RBAC is satisfied. Use icacls or Windows File Explorer from a machine with appropriate permissions (Storage File Data SMB Share Elevated Contributor) to inspect and correct the NTFS ACLs.
Primary source for this lesson Introduction to Azure Files — Microsoft Learn

Read the full introduction and follow the linked articles on identity-based authentication, Azure File Sync deployment, and cloud tiering. The Azure File Sync deployment guide is especially important for exam scenarios involving hybrid file sharing.

Questions for your teacher (the AI agent)
This lesson covered Azure Files architecture and Azure File Sync. Go deeper on any of these:
  • Walk me through setting up Azure File Sync from scratch, including registering a Windows Server and configuring cloud tiering.
  • How do you migrate an existing on-premises file server to Azure Files using the Azure File Sync pre-seeding workflow?
  • What are the exact steps to configure AD DS Kerberos authentication for Azure Files — what gets created in Active Directory?
  • How does Azure Files pricing work for Premium vs Standard, and when does the IOPS-to-cost ratio favour Premium over Standard?
Coming up: Lesson 09 — Virtual Machines: Configuration, Sizing & Availability With storage covered, we move to compute. Lesson 09 is one of the highest-weighted topics on AZ-104 — VM families, managed disks, disk caching, availability sets vs availability zones, VM extensions, and more. Expect exam questions that distinguish between 99.95% and 99.99% SLA guarantees.