Complete FSLogix Setup Guide for Azure Virtual Desktop: Step-by-Step Installation & Configuration Tutorial

Deliver persistent user experiences in non-persistent virtual desktop environments

If you’re deploying Azure Virtual Desktop (AVD), you’ve likely encountered the classic VDI challenge: how do you give users a persistent desktop feel when they’re connecting to pooled, multi-session hosts that reset after each session? The answer is FSLogix—and if you haven’t implemented it yet, this guide will walk you through the complete setup from storage configuration to your first successful user login.

What Is FSLogix and Why Do You Need It?

FSLogix (acquired by Microsoft in 2019) is a profile container technology that stores entire user profiles as virtual hard disks (VHD/VHDX files) on centralized storage. When a user connects to any session host in your pool, FSLogix mounts their personal VHD, giving them their complete desktop environment—files, settings, applications data—regardless of which physical VM they land on.

The problem it solves: Pooled host pools offer tremendous efficiency with multi-session Windows 10/11, but without profile management, users lose their customizations every time they log off. Traditional roaming profiles exist, but they perform poorly in virtual environments and often cause application compatibility issues.

FSLogix eliminates these performance bottlenecks by mounting profiles as local disks rather than copying files across the network, making the experience nearly indistinguishable from a physical PC.

Prerequisites: Get Your Storage Ready

Before touching a session host, you need Azure storage configured with Active Directory authentication. If you haven’t done this yet, you’ll need:

• An Azure Storage Account (Standard or Premium, depending on performance needs)
• Azure Files with Active Directory Domain Services (AD DS) or Azure AD DS authentication enabled
• A file share specifically for FSLogix profiles (the examples below use demo-profiles)

Step 1: Configure Azure RBAC Permissions

Here’s where many implementations stumble: Azure uses layered permissions, and you need both Azure RBAC and traditional file permissions.

Navigate to your storage account, then drill down to File Shares > [your-share-name] > Access Control (IAM).

Important: In recent Azure updates, RBAC moved from the storage account level to the individual file share level—so don’t look for it on the storage account overview blade.

Add these two role assignments:

Role	Assign To	Purpose
Storage File Data SMB Share Contributor	Your AVD Users group	Allows users to read/write their own profile VHDs
Storage File Data SMB Share Elevated Contributor	Your AVD Admins group	Gives administrators full control over all profiles

Click Add > Add role assignment, select the role, and assign it to the appropriate Azure AD group. The Contributor role gives users exactly what they need—read-write access without the ability to modify share-level permissions.

Step 2: Set NTFS-Level Permissions

Azure RBAC handles the Azure-side authentication, but once users connect via SMB, traditional Windows permissions apply. You need to set these from a domain-joined machine.

Map the Azure file share to a drive letter on a domain controller or management VM:

net use Z: \\[storageaccount].file.core.windows.net\demo-profiles

Then set permissions using ICACLS:

icacls Z:\ /grant "AVD Admins:(OI)(CI)F"
icacls Z:\ /grant "AVD Users:(OI)(CI)M"

This gives your admin group full control and users modify permissions—sufficient for FSLogix to create and expand VHD files as needed.

Step 3: Install FSLogix on Every Session Host

FSLogix must be installed on each session host in your pool. You have several deployment options depending on your environment size:

Small environments (2-5 hosts): Manual installation via Azure Bastion or RDP works fine. Download the FSLogix .zip from Microsoft, extract it, and run FSLogixAppsSetup.exe from the x64\Release folder.

Enterprise environments: Use your standard software deployment tool:

• Group Policy: The installer is an MSI, so you can deploy via GPO Software Installation
• Microsoft Intune/Endpoint Manager: Package the MSI for cloud-native management
• SCCM/MECM: Standard application deployment

Installation notes:

• No configuration choices during setup—accept the defaults (installs to C:\Program Files\FSLogix)
• No reboot required
• To verify installation, check for the C:\Program Files\FSLogix folder containing frx.exe and other binaries

Step 4: Understand the Local Groups

FSLogix creates four local groups on each session host during installation. Open lusrmgr.msc to see them:

• FSLogix ODFC Include/Exclude Lists – For Office container control (rarely used)
• FSLogix Profile Include/Exclude Lists – Control who gets FSLogix profiles

Default behavior: The “Profile Include List” contains “Everyone,” meaning all domain users get FSLogix profiles automatically.

When to use exclusions: Add accounts to the “Profile Exclude List” for:

• Local administrator accounts (they can’t write to Azure storage anyway)
• Temporary workers who don’t need persistent profiles
• Service accounts that log on interactively

Priority rule: Exclusions override inclusions. If a user is in both lists, they are excluded.

Step 5: Configure FSLogix via Group Policy

While you can configure FSLogix via registry keys on individual machines, Group Policy is the only scalable approach. FSLogix includes ADMX administrative templates for centralized management.

Import the templates:
Copy fslogix.admx and fslogix.adml from the FSLogix download package to your domain’s Central Store (\\domain\sysvol\domain\Policies\PolicyDefinitions) or a local PolicyDefinitions folder.

Required GPO settings (Computer Configuration > Policies > Administrative Templates > FSLogix > Profile Containers):

Setting 1: Enable FSLogix

• Policy: Enabled
• Value: Enabled
• Action: Check the “Enabled” checkbox

This simply turns the engine on. Without this, FSLogix installs but does nothing.

Setting 2: VHD Locations (Critical)

• Policy: VHD Locations
• Value: \\[storageaccount].file.core.windows.net\demo-profiles

Convert the Azure portal URL to UNC format:

• Remove https://
• Change forward slashes to backslashes
• Result: \\avdstorage123.file.core.windows.net\demo-profiles

This tells FSLogix where to store and retrieve user VHDs.

Setting 3: Delete Local Profile When FSLogix Profile Should Apply (Recommended)

• Policy: Delete local profile when FSLogix profile should apply
• Value: Enabled

Why this matters: If a user logged onto a session host before you implemented FSLogix, they have a local profile. FSLogix detects this and refuses to override it (safety feature). This policy says: “If FSLogix is supposed to apply, delete the local profile first, then create the container.”

⚠️ Warning: If users have important data in existing local profiles, back it up before enabling this. Once deleted, that data is gone.

Step 6: Verify Your Deployment

With configuration complete, it’s time to test. Have a user log into your AVD workspace.

First-time login indicators:

• Message appears: “Preparing FSLogix” or “Please wait for FSLogix”
• Login takes slightly longer (30-60 seconds) as FSLogix creates the initial VHD
• Default VHD size is approximately 1.8GB empty, 30GB capacity

Verification in Azure Portal:
Navigate to your storage account > File Shares > demo-profiles. You should see a new VHD file named [SID]_[Username].VHD.

Pro tip: The default naming puts the Security Identifier first, making it hard to identify users when you have hundreds of profiles. Enable the “FlipFlopProfileDirectoryName” policy to reverse this to [Username]_[SID].VHD for easier administration.

Step 7: Test Profile Persistence

The real test: does the profile follow the user?

1. Have your test user create a folder on their desktop or save a file to Documents
2. Log them off (you’ll see “FSLogix is unloading profile”)
3. Put the session host they used into Drain Mode (Host Pools > Session Hosts > Drain Mode)
4. Have the user log in again—they’ll connect to a different session host
5. Verify their test folder/file appears on the desktop

Success means FSLogix mounted their VHD on the new host seamlessly.

Performance and Sizing Considerations

User limits: FSLogix itself imposes no limits. Your constraints are session host capacity (CPU/RAM) and storage IOPS.

Storage sizing: Plan for:

• 10-30GB per user depending on application requirements
• Growth over time as users accumulate data
• Premium SSD or Azure NetApp Files for high-performance scenarios with 100+ users

Login performance: First login creates the VHD (slower). Subsequent logins simply mount the existing VHD (faster, typically 5-10 seconds).

Troubleshooting Quick Tips

Symptom	Likely Cause	Solution
No VHD created	FSLogix not enabled in GPO	Verify “Enabled” policy is applied
Local profile loads instead	Existing local profile blocking FSLogix	Enable “Delete local profile” policy or manually delete local profile
Access denied errors	Missing RBAC or NTFS permissions	Verify both Azure IAM roles and ICACLS permissions
Slow logins	Storage latency	Upgrade to Premium storage or check network path

Summary

FSLogix transforms Azure Virtual Desktop from a stateless experience into a personalized workspace. The implementation requires attention to detail—layered permissions, registry configuration, and proper testing—but the result is users who can’t tell they’re on a shared, non-persistent host.

With your profiles now centralized in Azure storage, you gain additional benefits: easy backup of VHD files, the ability to expand storage without touching session hosts, and the freedom to rebuild or replace session hosts without user data loss.

Your users get persistence. You get simplicity. That’s the FSLogix advantage.