##Create and configure a storage account for Azure Files.
Overview: Azure Storage is a Microsoft-managed service providing cloud storage that is highly available, secure, durable, scalable, and redundant. Azure Storage includes Azure Blobs (objects), Azure Data Lake Storage Gen2, Azure Files, Azure Queues, and Azure Tables.
In this applied skills exercise, I will demonstrate how to create a step by step guide in creating an #Azure storage account with a **** *globally unique name.
Step 1. Create a #storage account for the finance department’s shared files.
In the Azure *portal, search for and select *Storage accounts.
Select *+ Create.
For Resource group select Create new. Give your resource group a name, Let’s name it RG01 and select OK to save your changes.
Provide a Storage account name. Let’s use edmontonsa ensure the name meets the naming requirements.
Set the Performance to ****Premium.
Set the Premium account type to File shares.
Set the Redundancy to Zone-redundant storage. Our free subscription does not support zone-redundant storage so we used locally redundant storage (LRS)
Select Review and then Create the storage account.
Wait for the resource to deploy.
Select Go to resource.
We will Create and configure a file share with directory.
****Step 1. Create a file share for the corporate office
In the storage account, in the Data storage section, select the File shares blade.
Select + File share and provide a Name. Let’s name it myshare
Review the other options, take the defaults settings.
Select Create.
*Step 2. Add a directory to the file share for the finance department. For future testing, upload a file.
Select your file share and select *+ Add directory.
Name the new directory finance.
Select *Browse and then select the *finance directory.
Notice you can Add directory to further organize your file share.
Upload a file of your choosing.
Configure and test snapshots.
Step 1. Similar to blob storage, you need to protect against accidental deletion of files. You decide to use snapshots.
Select your file share.
In the Operations section, select the Snapshots blade.
Select *+ Add snapshot. The comment is optional. *Select OK.
Select your snapshot and verify your file directory and uploaded file are included.
Step 2. Practice using snapshots to restore a file.
Return to your *file share.
*Browse to your file directory.
Locate your *uploaded file and in the Properties, pane select *Delete. Select Yes to confirm the deletion.
Select the *Snapshots blade and then select your snapshot.
Navigate to the file you want to *restore,
Select the file and the select Restore.
Provide a Restored file name.
Verify your file directory has the restored file.
*Configure restricting storage access to selected virtual networks.
Step 1. This tasks in this section require a virtual network with subnet. In a production environment these resources would already be created.
Search for and select *Virtual networks.
Select Create. Select your resource group. and give the virtual network a name, *vnetlab01
Take the defaults for other parameters, select Review + create, and then Create.
Wait for the resource to deploy.
Select *Go to resource.
In the Settings section, select the *Subnets blade.
Select the default *subnet.
In the Service endpoints section choose Microsoft.Storage in the Services drop-down.
Do not make any other changes.
Be sure to Save your changes.
Step 2. The *storage account should only be accessed from the virtual network you just created
Return to your file’s storage account.
In the *Security + networking section, select the ****Networking blade.
In the *Virtual networks section, select *Add existing virtual network.
Select your ****virtual network and subnet, select Add.
Be sure to ****Save your changes. Always save your work after creating.
Select the *Storage browser and navigate to your *file share.
Verify the display ****“message not authorized to perform this operation”. You are not connecting from the virtual network.
Hope this article was helpful.
Top comments (3)
Storage account setup for Azure Files is the foundation; the production reality has a few extras:
Files vs Blob — Azure Files is SMB/NFS, Blob is object. Picking Files is correct for any 'I need a drive letter on Windows' workflow. Picking Blob is correct for cost-tier tiering and CDN-fronted content. Mixing them in one storage account complicates the access policy; keep them separate.
Storage account firewall — the default 'Allow all' is the wrong starting point. Lock to the VNet + a few specific public IPs from day one. Adding firewall rules later requires restarting clients (SMB share unmount) for the policy to take effect.
Azure File Sync — for multi-region or hybrid on-prem + cloud, Azure File Sync caches frequently accessed files on the local file server and only ships cold tiers to the cloud. The cache eviction policy is the knob that matters; tune per-share based on access patterns.
Mount layer for cross-platform SMB access on Windows: ScsDriver
Azure Files + AFS (Azure File Sync) for multi-site deployments: the storage account config matters more than people realize.
Storage account kind = FileStorage (not BlobStorage or GeneralPurpose v1). FileStorage accounts are locked to the v2 feature set with the file-specific performance tiers (transaction-optimized, hot, cool, premium).
Large File Shares — for shares >5 TiB you must enable 'Large file shares' at storage account creation time (cannot be retroactively enabled). For multi-site AFS where each server endpoint holds 10-50 TiB, large file shares is non-negotiable.
AFS cloud tiering policy — set 'volume free space percent' to 20% by default. Tiered files show as 'recall' status in Explorer with the cloud icon. When the user opens a file, AFS silently recalls it (transparent to the app). Recall latency is 100-500ms.
Multi-site topology — register each site as a server endpoint under the same sync group. Files modified at site A propagate to site B in 30-90s. Last-writer-wins conflict resolution is automatic; for true POSIX locking use SMB3 continuous availability.
Private Endpoint + Storage Account Firewall — for production, disable the storage account public network access and route through Private Link from each site. This is the secure default; the old 'Allow from All Networks' is no longer acceptable.
Backup via AFS snapshots — the storage account supports share snapshots (incremental, pay only for delta). For DR, automate snapshot creation via Azure Backup (Recovery Services vault) — gives you 99-year retention with cross-region restore.
For ops who want AFS shares to appear as native Windows drives in Explorer (rather than mapped drive letters that drop on reboot): ScsDriver
Some comments may only be visible to logged-in visitors. Sign in to view all comments.