Lesson: File Shares for Azure Virtual Desktop (AVD) Infrastructure

Introduction: The Foundation of User Persistence

When you design an Azure Virtual Desktop (AVD) environment, the compute layer—the virtual machines that host your users—is often the easiest part to plan. You provision your host pools, attach your images, and set your scaling plans. However, the true complexity and the most critical component for a successful user experience lies in how you manage user data. In a modern AVD deployment, we move away from traditional roaming profiles and folder redirection toward profile containers, specifically FSLogix.

FSLogix is the industry-standard technology for managing user profiles in virtualized environments. It captures the entire user profile in a VHDX file, which is then dynamically attached to the virtual machine when the user logs in. Because these profiles are stored as virtual disks, they must reside on a highly available, high-performance file share. Choosing the right storage backend for these containers is not just a technical detail; it is the single most important factor determining whether your users experience a fast, responsive desktop or constant "hanging" and application crashes.

This lesson explores the storage options for AVD, focusing on the configuration of file shares that host FSLogix profile containers. We will look at the performance requirements, the protocols involved, and the architectural decisions that separate a high-performing environment from one prone to performance bottlenecks.

The Role of FSLogix in AVD

Before diving into the storage hardware, we must understand why we need specialized file shares. Traditional Windows profiles are notorious for "profile bloat" and corruption. When a user logs into a virtual machine, the system copies thousands of small files from a network share to the local disk. This process is slow, especially as the profile grows, and it often results in synchronization errors.

FSLogix solves this by keeping the profile on the network share at all times. When a user logs in, the system mounts the VHDX file as a local drive (the C:\Users folder). Because the profile is "attached" rather than "copied," login times are significantly faster, and the user experience is identical to a physical PC. However, this architectural shift places immense demand on your storage infrastructure. Every single read and write operation the user performs—from opening an Outlook email to saving a Word document—travels over the network to the file share.

Callout: Why Standard File Shares Fail Many administrators attempt to use standard, low-cost file servers or basic storage accounts for FSLogix. This is a common mistake. FSLogix relies on constant, low-latency disk I/O. If your storage cannot handle the IOPS (Input/Output Operations Per Second) or the latency is too high, the user will experience "App-V" style hangs, where applications stop responding for seconds at a time. Always prioritize latency over raw capacity.

Storage Options for AVD

In the Azure ecosystem, you have three primary paths for hosting FSLogix profile containers. Each has different performance tiers, cost structures, and management requirements.

1. Azure Files (Premium Tier)

This is the recommended solution for almost all enterprise AVD deployments. Azure Files Premium uses Solid State Drives (SSDs) to provide consistent, low-latency performance. It supports the SMB protocol, which is required for FSLogix, and integrates directly with Active Directory or Microsoft Entra Domain Services.

2. Azure NetApp Files (ANF)

For massive, high-density, or mission-critical deployments, Azure NetApp Files offers unparalleled performance. It is a managed, enterprise-grade storage service built on NetApp technology. While it is more expensive than Azure Files, it provides predictable throughput and extremely low latency that can support thousands of concurrent users without degradation.

3. Azure Files (Standard Tier)

Standard Azure Files uses Hard Disk Drives (HDDs). While it is the most affordable option, it is generally not recommended for FSLogix production workloads. The latency variance on standard storage can cause significant user frustration during high-concurrency periods, such as "logon storms" in the morning.

Comparison Table: Storage Options

Implementing Azure Files Premium for FSLogix

To set up a production-grade file share, you must follow a specific sequence. We will use Azure Files Premium as the primary example because it is the most common choice.

Step 1: Create the Storage Account

You need a storage account configured for Premium performance. When creating this in the Azure Portal, ensure you select the "FileStorage" account kind.

1. Navigate to Storage Accounts in the Azure Portal.
2. Select Create.
3. Choose your Resource Group and provide a name.
4. Under Performance, select Premium.
5. Under Premium account type, select File shares.
6. Ensure Redundancy is set to LRS (Locally-redundant storage) unless you have specific geo-replication requirements.

Step 2: Configure Networking

Security is paramount. You should never expose your storage account to the public internet. Use Private Endpoints to ensure all traffic between your AVD host pools and the storage account stays within the Azure backbone network.

1. Inside your new Storage Account, go to Networking.
2. Select Private endpoint connections.
3. Click + Private endpoint.
4. Configure the endpoint to connect to the file sub-resource.
5. Ensure the endpoint is placed in the same Virtual Network as your AVD session hosts.

Step 3: Identity-Based Access

FSLogix requires that the session hosts (the virtual machines) have the correct permissions to read and write to the file share. You must enable Active Directory (AD) or Microsoft Entra Domain Services (formerly Azure AD DS) authentication on the storage account.

Note: Permissions Are Two-Fold Setting up storage access requires two distinct sets of permissions: Share-level (Azure RBAC) and NTFS-level (File System permissions). You must configure both, or users will be unable to mount their profile containers.

Configuring Share-Level Permissions

1. Navigate to your Storage Account.
2. Go to Access Control (IAM).
3. Add a role assignment for "Storage File Data SMB Share Contributor" to the group containing your AVD session host computer accounts.

Configuring NTFS-Level Permissions

Once the share is created, you must map the share to a machine and set the specific NTFS permissions:

• Creator Owner: Full Control (Subfolders and files only)
• Authenticated Users: Read/Write/Modify (This folder only)
• Domain Admins: Full Control

Best Practices for Performance and Stability

1. The "Logon Storm" Problem

A logon storm occurs when hundreds of users attempt to log in at 8:00 AM. This creates a massive spike in IOPS. If your file share is throttled, users will wait minutes for their desktop to load. To mitigate this, consider using "Bursting" capabilities in Azure Files Premium or over-provisioning your initial capacity. Azure Files Premium performance is tied to the provisioned capacity; if you have a small share, you have low IOPS. If you find your IOPS are hitting the ceiling, simply increase the share size—even if you don't need the extra space—to unlock higher performance tiers.

2. Directory Structure and Organization

Do not store all user profile VHDXs in a single flat folder if you have more than 500 users. While modern file systems handle this better than older ones, it is still best practice to implement a subdirectory structure. FSLogix supports this via the VHDLocations configuration, allowing you to distribute profiles across multiple shares if necessary.

3. Monitoring and Alerts

You cannot manage what you do not measure. Configure Azure Monitor alerts on your storage account for the following metrics:

• SuccessE2ELatency: This measures the time from the request being received to the response being sent. If this spikes above 10-20ms, your users will feel it.
• Transactions: Monitor this to see if you are approaching your IOPS limits.
• Used Capacity: Ensure you have enough buffer to prevent the share from filling up, which would result in immediate profile corruption.

Callout: The Dangers of Profile Corruption If a file share runs out of space or loses connectivity while a user is logged in, the VHDX file can become corrupted. FSLogix will attempt to repair it, but this often leads to data loss. Always implement a "soft quota" alert at 80% capacity so you have time to expand the share before it becomes a critical issue.

Common Pitfalls and How to Avoid Them

Pitfall 1: Using the Wrong Protocol

Some administrators attempt to use Azure Blob storage with NFS or other protocols. FSLogix specifically requires SMB. Ensure your session hosts are running the necessary services to handle SMB 3.0 encryption, which is enabled by default in Azure Files for security reasons.

Pitfall 2: Neglecting Computer Account Permissions

A common mistake is granting permissions to the user only. In an AVD environment, the machine (the session host) is the one mounting the share. Ensure the computer accounts of your AVD session hosts are joined to the domain and have the correct RBAC roles assigned on the storage account.

Pitfall 3: Ignoring Latency

Many teams focus on bandwidth (throughput) but ignore latency. A file share might have 1Gbps of throughput, but if the round-trip time (RTT) is high, the FSLogix mount process will time out. Always keep your storage account in the same Azure region as your AVD host pool.

Advanced Configuration: FSLogix Settings

The fslogix.ini file is where you define how the profile container interacts with the file share. Below is a standard configuration snippet for a production environment.

[FSLogix]
; Enable FSLogix Profiles
Enabled=1

; The path to your file share
VHDLocations=\\yourstorageaccount.file.core.windows.net\profiles

; Set the size of the VHDX in MB (e.g., 30GB)
SizeInMBs=30720

; Ensure the profile is stored in a subfolder for better management
; This helps avoid hitting file count limits in a single directory
VolumeType=VHDX

; Ensure the profile is deleted from the host on sign-out
DeleteLocalProfileWhenVHDShouldBeDetached=1

Explanation of settings:

• Enabled=1: Activates the engine.
• VHDLocations: Points to the SMB path. Note that you must use the Fully Qualified Domain Name (FQDN) of the storage account.
• SizeInMBs: Sets the maximum size of the virtual disk. 30GB is generally sufficient for most office workers.
• DeleteLocalProfileWhenVHDShouldBeDetached: This is vital. It prevents "ghost" profiles from accumulating on the session host's local disk, which can eventually fill up the C: drive and crash the VM.

Troubleshooting Connectivity

If your users are failing to log in, the first step is to verify the connection from the session host. Log into one of the AVD session hosts as an administrator and attempt to map the drive manually:

# Run this from the AVD Session Host
net use Z: \\yourstorageaccount.file.core.windows.net\profiles /persistent:yes

If this command fails, check the following:

1. Network Security Groups (NSGs): Ensure port 445 is open for outbound traffic from the session host to the storage account.
2. DNS Resolution: Can the VM resolve the storage account name?
3. Time Sync: If the VM's clock is significantly out of sync with the domain controller, Kerberos authentication will fail.

Industry Recommendations for Scale

As your AVD environment grows, you will eventually reach the limits of a single Azure Files share. Azure Files Premium has a maximum capacity (typically 100TiB) and a maximum IOPS limit. When you reach these limits, you must implement a "sharding" strategy.

Sharding involves splitting your users across multiple storage accounts. Instead of pointing all users to one share, you use logic (such as Group Policy Objects or Environment Variables) to point different host pools or user groups to different storage accounts.

Tip: Use DFS-N for Abstraction To make your life easier, use Distributed File System Namespace (DFS-N). Instead of hardcoding \\storageaccount1.file... in your GPOs, you create a DFS namespace like \\contoso.com\profiles. If you ever need to migrate users to a new storage account, you simply update the DFS target. The end-users and the FSLogix configuration remain unchanged.

Summary of Best Practices

• Always use Premium Storage: Do not compromise on performance for production user profiles.
• Keep it Local: Ensure your storage account and AVD host pools are in the same Azure region to keep latency at a minimum.
• Security First: Use Private Endpoints and restrict access to the storage account via RBAC.
• Plan for Growth: Monitor your IOPS and capacity regularly. Use alerts to notify you before you hit hard limits.
• Standardize with GPO: Always use Group Policy or Intune to manage FSLogix configurations across your fleet to ensure consistency.
• Test with Reality: During your pilot phase, simulate a login storm to see how your storage handles the pressure.

Key Takeaways

1. FSLogix is non-negotiable: It is the standard for modern AVD environments because it decouples the user profile from the OS, allowing for faster logins and better persistence.
2. Storage performance dictates user satisfaction: The most common cause of poor AVD performance is a bottlenecked file share. Prioritize low latency (SSD-based) storage over cheap, high-capacity HDD storage.
3. Permissions require a two-tier approach: You must configure both Azure RBAC (share-level) and NTFS (file-level) permissions to ensure users can access their profile containers.
4. Networking matters: Always use Private Endpoints for your storage accounts to keep traffic off the public internet and improve security.
5. Proactive monitoring is essential: Use Azure Monitor to track latency and capacity, and set up alerts to catch issues before they affect your users.
6. Abstraction simplifies management: Consider using DFS-N to provide a consistent namespace for your profile shares, allowing you to migrate or add storage without reconfiguring your entire host pool.
7. Maintenance prevents failure: Regularly audit your session hosts to ensure local profiles are being cleaned up and that your storage account isn't hitting IOPS thresholds during peak hours.

By following these guidelines, you will build a resilient, high-performing storage architecture that supports your users regardless of how fast your organization scales its virtual desktop footprint. Remember that the goal is to make the virtual desktop feel as snappy and reliable as a physical machine; the file share is the "heart" that keeps that experience alive.