By the end of this build sheet you have a working Azure file share on the provisioned v2 billing model, reachable over the internet with encrypted SMB, mounted as a drive letter on an Entra-joined Windows 11 device, authenticated with your Entra credentials and no domain controller anywhere. This is the starter posture: real enough to evaluate honestly, small enough to build in an hour.
Prerequisites: an Entra ID tenant; an Azure subscription where you hold Owner or Contributor plus the ability to grant admin consent (Global Administrator or Privileged Role Administrator for one consent prompt); a test device that is Microsoft Entra joined (not hybrid, not domain-joined) running Windows 11 24H2 with at least KB5079391 (build 26100.8116 or later), 25H2 with the same KB at build 26200.8116 or later, 26H1 or newer with at least KB5079489 (build 28000.1764 or later), or Windows Server 2025 with current cumulative updates (Windows 10 is not supported for cloud-only identities); and an internet connection that allows outbound TCP 445 (Step 6 tests this before you waste time on it). No Azure Files feature here requires a specific Microsoft 365 license.
Three more things, on the machine and in the tenant, that nothing in the portal will tell you about. The IP Helper service (iphlpsvc) and the WinHTTP Web Proxy Auto-Discovery Service (WinHttpAutoProxySvc) must both be running on every client that mounts the share. Hardened builds disable both as a matter of routine, and the second is the trap: you may disable Web Proxy Auto-Discovery itself by registry, but not the service, because it also carries Kerberos KDC proxy requests and the mount depends on them. In the tenant, if application management policies block symmetric key addition on service principals or cap symmetric key lifetime below 366 days, grant an exception to the Storage Resource Provider, application ID a6aa9161-5291-40bb-8c5c-923b567bee3b; in the admin centre those are the “Block password addition” and “Restrict max password lifetime” settings.
Step 1: Create the storage account
Azure Files lives inside a storage account, and the account kind decides which billing models you can use. You want the FileStorage kind with a provisioned v2 SKU. The media tier and the region are not performance choices here. They are identity choices, and this is the first place in the series where the identity model reaches back and constrains the infrastructure. Assigning share-level RBAC to specific cloud-only users and groups is available in a published subset of Azure regions, and in the United States that subset is US West Central on SSD only. Build the pilot there and the identity work two articles from now lands intact. Build it on HDD, or in a region off the list, and you reach a wall with an account you cannot move, because the identity source and the media tier are both fixed at creation.
In the portal, create a storage account and in the create flow set the primary service to Azure Files, Performance to Premium, File share billing to Provisioned v2, and redundancy to LRS for a test. Name it within the global storage rules: 3 to 24 characters, lowercase letters and numbers only. The name becomes your UNC path, so pick something you can read aloud: I use a pattern like stvcio<purpose><seq>, for example stvciofiles01.
The consolidated CLI equivalent:
az group create --name rg-files-pilot --location westcentralus
az storage account create `
--name stvciofiles01 `
--resource-group rg-files-pilot `
--location westcentralus `
--kind FileStorage `
--sku PremiumV2_LRSExpected result: an account of kind FileStorage with SKU PremiumV2_LRS. If the SKU is rejected, that region does not offer SSD provisioned v2; check the availability list before choosing another, because the identity constraint above has already narrowed the field considerably. The classic failure mode here is creating a StorageV2 account out of habit, which silently lands you on the legacy pay-as-you-go model, the one with transaction billing. Check the kind before moving on: az storage account show --name stvciofiles01 --query kind must return FileStorage.
Step 2: Confirm the security defaults
Portal-created accounts now require encryption in transit for SMB by default, which is exactly what you want for a share you are about to reach over the internet. Verify rather than assume, because accounts created through CLI and templates leave the setting unset for backward compatibility. On the storage account, under the file share settings, confirm that encryption in transit is required and that the SMB security profile allows only SMB 3.1.1 with AES-128-GCM or AES-256-GCM channel encryption. Leave NTLMv2 enabled for now; it is what the storage account key uses, and Step 7’s troubleshooting fallback needs it. Retiring NTLMv2 properly is covered in the private endpoint build sheet.
Step 3: Create the share
Provisioned v2 asks you for three numbers: storage, IOPS, and throughput. For a pilot, take the recommended values; you can raise any dial at any time (lowering is locked for 24 hours after any raise, which is the one rule worth remembering).
| Setting | Value | Why |
|---|---|---|
| Name | pilot | Share names are lowercase; this one is disposable and the name should say so. |
| Provisioned storage | 100 GiB | Provisioned v2 floors at 32 GiB on either media tier. 100 GiB leaves room for a real test dataset without provisioning performance nobody will use. |
| Provisioned IOPS | 3,100, the recommended value at this size | SSD provisioned v2 recommends 3,000 plus one IOPS per provisioned GiB, on a floor of 3,000. You can override it, up to five times the recommendation. |
| Provisioned throughput | 110 MiB/s, the recommended value at this size | SSD provisioned v2 recommends 100 MiB/s plus 0.1 MiB/s per provisioned GiB, on a floor of 100 MiB/s. The same five times ceiling applies. |
az storage share-rm create `
--storage-account stvciofiles01 `
--resource-group rg-files-pilot `
--name pilot `
--quota 100 `
--provisioned-iops 3100 `
--provisioned-bandwidth-mibps 110Expected result: the share appears under the account’s file shares with 100 GiB provisioned and the IOPS and throughput you specified. On a provisioned v2 account the portal shows all three dials on the share’s configuration; confirm you see provisioned IOPS and throughput listed, because their presence is your proof you are on v2 and not the legacy model.
Step 4: Enable Microsoft Entra Kerberos
This is the step that was impossible for cloud-only estates before May 2026, and it is now two actions: enable the identity source, then consent to the application it creates.
On the storage account, under Data storage select Classic file shares, then next to Identity-based access select the configuration status and enable Microsoft Entra Kerberos. In PowerShell:
Set-AzStorageAccount `
-ResourceGroupName "rg-files-pilot" `
-StorageAccountName "stvciofiles01" `
-EnableAzureActiveDirectoryKerberosForFile $trueEnabling the source auto-creates an Entra application named [Storage Account] stvciofiles01.file.core.windows.net. It needs admin consent for its sign-in permissions (openid, profile, User.Read). Find it in Entra admin center under enterprise applications and grant admin consent once. Do not otherwise touch this app, with one exception you will meet in the identity build sheet (a manifest tag for cloud-only groups). Failure mode: skip the consent and every mount attempt fails with a generic credential error that says nothing about consent; if your first mount fails, check this before anything else.
Step 5: Grant share-level permission
Azure Files authorizes in two layers: an Azure RBAC gate at the share level, then NTFS ACLs beneath it, and the most restrictive of the two wins. For the starter build, set the default share-level permission so every authenticated user in your tenant passes the gate as a contributor, and let ACLs do the fine work later. It is also the setting that works everywhere, which matters if you ever repeat this build outside the region Step 1 chose: assigning RBAC to specific cloud-only users and groups is region-limited, and the default share-level permission is not.
Set-AzStorageAccount `
-ResourceGroupName "rg-files-pilot" `
-StorageAccountName "stvciofiles01" `
-DefaultSharePermission StorageFileDataSmbShareContributorExpected result: the storage account reports the default share permission as Contributor. RBAC changes can take up to 30 minutes to propagate; start Step 6 while you wait. A default permission for all authenticated users sounds loose, and for production it is; the identity build sheet replaces it with named groups. For a pilot share holding nothing sensitive, it is the right simplification.
Step 6: Prepare the client and test the path
Two client-side facts decide whether the mount works. First, the device must be told to request cloud Kerberos tickets. On an Intune-managed device, deploy the setting Kerberos > Cloud Kerberos Ticket Retrieval Enabled from the settings catalog; on a lone test machine, set the registry value directly and reboot:
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters `
/v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1 /fThat setting has a consequence worth understanding before you push it to a fleet. Once a client is retrieving cloud Kerberos tickets it can no longer reach storage accounts joined to on-premises AD DS, unless you also give it a host name to Kerberos realm mapping for each of those accounts. In a pure cloud-only estate this costs nothing. In a mixed estate it is a fleet-wide change that breaks a different set of shares, and the breakage lands nowhere near the policy that caused it. The mapping is delivered by the Kerberos/HostToRealm policy in Intune, by the “Define host name-to-Kerberos realm mappings” group policy, or by ksetup /addhosttorealmmap, one entry per AD DS-joined storage account. Realm names are uppercase and case sensitive.
Second, outbound TCP 445 must actually reach Azure. Most US cable providers and phone hotspots block it; fiber, business circuits, and most corporate egress usually allow it. Test before you troubleshoot anything else:
Test-NetConnection -ComputerName stvciofiles01.file.core.windows.net -Port 445Expected result: TcpTestSucceeded : True. If it is False, nothing in Azure is wrong; your network path is eating port 445. Move to a network that allows it for this pilot (tether to a hotspot that permits 445, or run the test from an office circuit), and take the hint: your production access path will be a private endpoint over VPN or Global Secure Access, both of which have their own build sheets in this series.
Step 7: Mount and validate
Sign in to the test device as a normal Entra user (not a local account), then mount:
net use Z: \\stvciofiles01.file.core.windows.net\pilotNo username, no password, no key. Expected result: the command completes and Z: opens in Explorer. Prove the authentication is what I claim it is:
klist get cifs/stvciofiles01.file.core.windows.netYou should see a Kerberos ticket for the share’s service principal issued by the realm KERBEROS.MICROSOFTONLINE.COM. That realm name is the whole story of this article: the ticket came from Entra ID, not from a domain controller, because there is no domain controller.
The end-to-end test: create a file on Z:, then open the share in the portal’s file browser and confirm the file is there. Then do it in reverse, upload a file in the portal and watch it appear in Explorer. If both directions work, you have a functioning cloud file share with identity-based access.
If the mount fails with a credential prompt or system error 1327 and your tenant enforces MFA broadly through Conditional Access, you have met the platform’s most important limitation early: the SMB flow cannot satisfy an MFA requirement, and the storage account’s app must be excluded from MFA policies. The identity article covers why, and what I do about it. As a last-resort diagnostic (not a fix), mounting with the storage account key isolates whether the problem is identity or network: net use Z: \\stvciofiles01.file.core.windows.net\pilot /user:Azure\stvciofiles01 <storage-key>. If the key mounts and Kerberos does not, work the identity chain: consent, RBAC propagation, the registry value, the sign-in account.
Where this leaves you
You now have the starter posture: a hardened public endpoint, encrypted SMB, Entra Kerberos, one share, one drive letter. It is a real deployment in miniature, and everything from here is a deliberate upgrade of one layer at a time. The identity doctrine article and its build sheet replace the default share permission with named groups and real ACLs. The networking articles decide whether production traffic rides this public endpoint, a private endpoint over your VPN, or Global Secure Access. Keep the pilot share; the rest of the series keeps using it.
Azure Files
‹ Previous: [AF 1] Azure Files: The File Server Question, Re-Asked
Next: [AF 2] Identity: Who Your File Server Trusts Now ›
