Modernizing Your File Shares: Moving from On-Prem SMB to Azure Native Solutions

For years, on-premises servers with SMB (Server Message Block) paths have been the backbone of corporate file sharing. A path like \ SERVER-Name\Share is familiar to every employee. But as businesses embrace the cloud, a more modern, secure, and scalable approach is needed. This is where Azure’s native file services come in.

AWS leverages the Amazon FSx suite — specifically FSx for Windows File Server or FSx for NetApp ONTAP — for file system services. AWS assigns a strictly managed, internal DNS hostname to each file system upon creation. When the endpoint is configured in a Multi-AZ deployment, AWS provides an alternative routing mechanism through DNS aliases, enabling seamless failover and uninterrupted access across subnets.

We can also explore the same things with GCP. Google Cloud utilises its native Google Cloud NetApp Volumes (and Google Cloud Filestore for NFS).During volume creation, Google registers an SMB server hostname with the configured Active Directory. Ex path :\gcp-smb-server.corp.mydomain.com\Share-Path

Based on a recent migration project, let’s explore the journey from a traditional on-prem setup to a cutting-edge Azure SMB path.

The Old Way: The On-Prem SMB Path

An on-premises file share is straightforward: a physical or virtual server on your local network hosts files and folders. Access is managed through traditional Active Directory, and users connect from their domain-joined computers. • Path: \Server-Name\Share-Path • Infrastructure: Requires managing servers, storage hardware, backups, and network security. • Accessibility: Primarily designed for users within the corporate network. VPN is required for remote access, which can add complexity and performance overhead.

The New Way: The Azure SMB Path

An Azure-native approach replaces the on-prem server with a cloud-based storage account. This provides a fully managed, highly available, and secure platform for your file shares. • Path: https://Storage-Name.file.core.windows.net/Share-Path • Infrastructure: Fully managed by Azure. No more server patching, hardware failures, or manual capacity planning. Azure handles availability, redundancy, and backups. • Accessibility: Designed for the modern hybrid workforce. Secure access is possible from anywhere using modern authentication (like Microsoft Entra ID), without relying solely on traditional VPNs.

Key Advantages of the Azure Approach

1. Reduced Overhead: Eliminates the need to manage physical servers, reducing maintenance costs and freeing up IT resources to focus on value-added tasks.

2. Enhanced Security: Azure provides a robust security framework. By using Private Endpoints, file shares can be made accessible only through your secure virtual network, completely blocking public internet access. Identity is managed through Microsoft Entra Kerberos, ensuring that only authenticated and authorized users can access data.

3. Scalability and Performance: With Azure’s provisioned performance models, you can customize the capacity, IOPS (Input/Output Operations Per Second), and throughput to match your exact workload needs. Need more performance during peak business hours? You can adjust it without buying new hardware.

4. Integrated Data Protection: Azure Backup is built-in. You can configure automated daily backups with long-term retention policies directly from the Azure portal, ensuring your data is protected against accidental deletion or corruption.

The move from a legacy on-prem path to an Azure SMB path is more than just a change in address; it’s a strategic shift toward a more agile, secure, and cost-effective file storage solution.

Architecture

Business Advantages

• Shift to OpEx and Cost Optimisation: Transitioning to a cloud-based file share model converts unpredictable, large capital expenditures (CapEx) into predictable, subscription-based operating expenses (OpEx). This approach eliminates the need to over-provision hardware in anticipation of future growth.
• Global Accessibility and Hybrid Productivity: By reducing reliance on traditional, bottleneck-prone corporate VPNs, remote employees can securely access cloud file shares from any location worldwide, enabling seamless and real-time collaboration across geographically distributed teams.
• Rapid Deployment and Operational Agility: Establishing a secure file-sharing environment for new business units, partnerships, or audit requirements can be accomplished within minutes in the cloud, as opposed to the extended timelines associated with procuring and configuring on-premises infrastructure.
• Regulatory Compliance and Audit Readiness: Cloud service providers offer built-in enterprise-grade logging and compliance capabilities, allowing organisations to accurately track user activity, including access, modification, and deletion of sensitive data, thereby facilitating audit and regulatory requirements.

Technical Advantages

• Minimal Infrastructure Overhead (PaaS): Cloud-based file sharing solutions are inherently serverless, removing the need for engineering teams to manage operating systems, perform infrastructure updates, or maintain physical hardware.
• Automated Data Protection and Snapshots: Backup and disaster recovery mechanisms are natively integrated into cloud platforms, enabling automated scheduling of read-only snapshots and cross-region data replication to safeguard against ransomware attacks and physical failures.
• Secure Networking through Private Endpoints: Although accessible via the internet, cloud file shares can remain non-public. Through Private Endpoints (Private Links), data traffic is routed via private IP addresses within a Virtual Private Cloud (VPC), significantly reducing exposure to external threats.
• Intelligent Storage Tiering: Cloud platforms can dynamically analyse data access patterns, ensuring that frequently accessed (“hot”) data resides on high-performance storage, while infrequently accessed (“cold”) data is automatically transitioned to cost-efficient archival tiers — without altering the end-user experience or file access paths.

Creating File storage

Storage accounts have two properties, kind and SKU, which dictate the billing model, media tier, and redundancy of the file shares that you can deploy in the storage account. For Azure Files, consider three main combinations of kind and SKU. We will use here Storage V2 and SKU will be Premium LRS.

We will go step by step :

Step1 :we will login to portal.azure.com . In search bar we will search storage account

Step 2: create new storage account name and should be aligned with Vorwerk standard

Step 3: fill out the information like subscription, RG, Storage account name , region , storage types, Performance, file share billing , redundancy etc.

Step 4 : As per the requirement, you can attach a private endpoint to your storage path to ensure secure access. This helps restrict connectivity to your storage resources over a private network rather than exposing them to the public internet.

From a best practices standpoint, I strongly recommend attaching the private endpoint directly to your storage account. This approach provides a more consistent and secure configuration, simplifies network management, and ensures that all associated storage services are accessed securely through the private endpoint.

Identity Based Access :

We have to enable identity-based authentication on your storage account, decide which identity source to use. enable identity-based authentication over SMB by using one of three identity sources: On-premises Active Directory Domain Services (AD DS), Microsoft Entra Domain Services, or Microsoft Entra Kerberos. we can use only one identity source for file access authentication per storage account, and it applies to all file shares in the account.

On-premises AD DS: The storage account joins to the on-premises AD DS. Identities from AD DS can securely access SMB Azure file shares from a domain-joined client or a client that has uninterrupted connectivity to the domain controller.

Microsoft Entra Kerberos: we can use Microsoft Entra ID to authenticate hybrid or cloud-only identities (preview), allowing end users to access Azure file shares. If you want to authenticate hybrid identities, you need an existing AD DS deployment, which you then sync to your Microsoft Entra tenant.

Microsoft Entra Domain Services: Cloud-based VMs that are joined to Microsoft Entra Domain Services can access Azure file shares with Microsoft Entra credentials. In this solution, Microsoft Entra ID runs a traditional Windows Server AD domain that is a child of the customer’s Microsoft Entra tenant.

Grant admin consent to the new service principal

After enabling Microsoft Entra Kerberos authentication, grant admin consent to the new Entra application registered in your Entra tenant. This service principal is autogenerated and isn’t used for authorization to the file share, so don’t make any edits to the service principal other than those documented here.

configure the API permissions

1. Open Microsoft Entra ID.

2. In the service menu, under Manage, select App registrations.

3. Select All Applications.

4. Select the application with the name matching [Storage Account] Storagepath.file.core.windows.net

5. In the service menu, under Manage, select API permissions.

6. Select Grant admin consent for [Directory Name] to grant consent for the three requested API permissions (openid, profile, and User.Read) for all accounts in the directory.

7. Select Yes to confirm.

manifest the storage

We need to manifest the storage and to add the privateLink FQDN to the storage account’s Microsoft Entra application before you mount the file share. You can add the required identifierUris to the application object using the portal.azure.com.

Add the privateLink FQDN to the Storage Account Application

Before mounting the file share, it is necessary to update the storage account’s Microsoft Entra application by including the privateLink Fully Qualified Domain Name (FQDN). This process is referred to as manifesting the storage.

Steps to Modify the Application Manifest

1. Open the Microsoft Entra ID service in the Azure portal (portal.azure.com).

2. In the left pane, under Manage, select App registrations.

3. Click on All Applications and locate the application that matches the name of your storage account (for example, [Storage Account] Storagepath.file.core.windows.net).

4. Select the application, then in the left pane, choose Manifest.

5. Add the required privateLink FQDN as an identifierUri entry in the application object.

6. Save the changes to update the manifest.

By completing these steps, the privateLink FQDN will be included in the storage account’s Microsoft Entra application, ensuring the necessary configuration is in place for mounting the file share.

Create a Provisioned v2 File Share

Overview

The classic file share is established using the provisioned v2 billing model. With this model, you have the flexibility to specify the storage capacity, input/output operations per second (IOPS), and throughput required for your file share. These parameters are determined based on your unique requirements.

Billing Model

The total bill for your file share is calculated according to the amounts of storage, IOPS, and throughput that you provision. As you define these quantities, the service automatically provides recommendations for the necessary IOPS and throughput, which are based on the amount of storage you have specified.

Customising Performance

While the service offers guidance on recommended values for IOPS and throughput, you may find that your needs differ from these suggestions. Depending on your operational requirements, you can choose to provision more or less IOPS and throughput than the recommended values to best suit your workload.

Follow these instructions to create a provisioned v2 classic file share by using the Azure portal.

Step 1: Go to your storage account. From the service menu, under Data storage, select File shares.

Step 2 Create File share: File name should be in lower case only. Size should not be less than 32 GB. Fill the appropriate information Like : name , size, Protocol

Step 3 Configure Backup

During the creation of a file share, it is mandatory to enable the backup policy to ensure data protection and compliance. If a standard backup policy is already available and configured in our landing zone, the same policy can be reused. Alternatively, if there is a specific requirement, a new backup policy can also be created and associated with the file share.

When configuring the backup for the first time in a particular storage account, you will need to explicitly select the Recovery Services Vault (RSV) to be used for backup. Once this initial selection is completed, the storage account retains this configuration. For any subsequent file share creations within the same storage account, the previously selected RSV will be automatically picked by default, eliminating the need for manual selection again.

This approach helps maintain consistency across backups, reduces configuration effort for future file shares, and ensures that all data is protected as per the defined backup standards.

Step 4 Review + Create

Configure the permission

Share path( ex: mysuccess) -> IAM ->add-> add role assignment -> choose Storage File Data SMB Share Contributor and Storage File Data SMB Share Elevated Contributor and for admin Storage File Data SMB Admin-> choose user or group → next-> review+assign

• Storage File Data SMB Share Contributor: Grants read, write, and delete access. This is the standard role for users who need to upload and manage files.
• Storage File Data SMB Share Elevated Contributor: Grants read, write, delete, and the ability to modify Windows ACLs.
• Storage File Data SMB Admin: Provides admin-level access equivalent to the storage account key, typically used for managing permissions and initial setup.

When executing a Proof of Concept (POC), we typically assign broader role access — such as Storage File Data SMB Share Elevated Contributor — to all data producers. This approach helps expedite testing and validation activities by avoiding access-related blockers during the POC phase.

However, when transitioning to the production environment, it is critical to follow a least-privilege access model and clearly understand the scope and responsibilities of each user. Permissions should be granted strictly based on the actual operational requirements rather than replicating the broader POC access.

For example:

• If a user’s responsibility is limited to managing or working with data (read/write operations) within an existing share, the appropriate role to assign is Storage File Data SMB Share Contributor.
• If a user is responsible for managing the folder structure within the share path — such as creating, modifying, or deleting directories — then the Storage File Data SMB Share Elevated Contributor role should be provided.
• This distinction ensures better security governance, reduces the risk of unintended changes, and aligns with production best practices by granting users only the permissions necessary to perform their assigned tasks.

Configure Client Prerequisites

Windows Clients: Target machines must be Microsoft Entra joined or Microsoft Entra hybrid joined.

Network Coexistence: For hybrid users, configuring granular directory/file-level Windows ACL permissions still requires the administrative device to have network line-of-sight to the on-premises domain controller

Testing

Execute the below script from the end user’s laptop. Please ensure that the User Laptop CIDR range is whitelisted on the Azure Firewall prior to execution. Wherever (laptop or server) you intend to map or use the SMB path, the same script must be executed locally on that system using PowerShell with the required privileges.

The primary objective of this activity is to validate network connectivity and accessibility of the Azure Files storage endpoint (Storage-Name.file.core.windows.net/Share-Path) from the end user system. This validation specifically focuses on confirming access over a non 445 port, as port 445 may be restricted or blocked in certain network environments.

Successful execution of this script will help verify that the storage path is reachable from the client machine, that firewall rules and network routing are correctly configured, and that there are no connectivity issues from the user endpoint to the Azure Files service. This check is a prerequisite before proceeding with any SMB path mapping or application usage that depends on this storage account.

For Human User

For Service Account with manual User Id & Password

Next Steps for Your Cloud Journey

Moving from an on-prem SMB path to an Azure-native solution provides unparalleled security, scalability, and ease of management. Don’t let legacy infrastructure hold back your digital transformation. If you are ready to reduce maintenance overhead and secure your file shares for the modern workforce, start by assessing your current on-premises data footprint today. Plan your proof-of-concept, test your Entra ID integration, and take the first step toward a fully managed cloud storage solution