Azure Virtual Desktop with FSLogix: profile storage latency, locks and sizing

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

An FSLogix profile container is a VHD or VHDX file that each session host attaches over SMB at sign-in. A slow sign-in is therefore usually one of four things: the distance to the share, a throttled share, a stuck lock on one user's file, or a session host that is simply overloaded. Each leaves different evidence, and the fixes do not overlap, so find the evidence before you change a setting or buy more IOPS.

By default a user can hold only one read-write attachment to a container, and the default retry settings make a stuck lock cost about a minute of waiting before FSLogix gives up. Capacity is rarely the first limit you should size for. Peak sign-in activity is.

The commands below come from Microsoft's published references. They were not run in a lab for this article.

Why it matters

Microsoft recommends FSLogix profile containers for Azure Virtual Desktop and Azure Files for most customers. The same vendor also states that FSLogix doesn't provide storage architecture or design guidance, and that network latency, bandwidth and proximity to the storage provider are pivotal. The design work is yours.

The failure shows up as users waiting at a welcome screen, landing on a temporary profile, or being refused sign-in. A temporary profile is the most damaging of those, because the user may work for hours before realising their usual data is not there.

How it works

At sign-in, FSLogix finds the user's folder under VHDLocations, opens the container, attaches it and redirects the profile into it. The folder is named %sid%_%username% by default. Microsoft's own log examples show a file named like Profile_jdoe.vhdx.

Two properties of this design drive everything else.

One file, one owner. FSLogix maintains an exclusive lock on the user's container while they are connected and concurrent connections are disabled. Microsoft also states plainly that concurrent connections are not supported by session hosts in an Azure Virtual Desktop host pool. So ProfileType should stay at 0 in a host pool. Microsoft's reference says that if the VHD isn't accessed concurrently, ProfileType should be 0, and that 0 must not be mixed with other values.

Metadata moves inside the disk. Microsoft's Azure Files guidance explains that when a client mounts a VHD from a share, the file system is owned by the client, so metadata operations are local. Once attached, thousands of small profile operations become block reads and writes against one file. The share still sees opens, closes and attribute queries around attach and detach. The inference is that metadata pressure concentrates in the sign-in and sign-out peaks, while data IOPS and the per-file limit govern the working session. Microsoft does not state it in those terms.

Finding the cause of a slow sign-in

Work in this order. Each step removes a whole class of cause.

1. Time the profile load on the host

Open C:\ProgramData\FSLogix\Logs\Profile\Profile_%date%.log on the session host. Microsoft's log guidance suggests searching for LoadProfile: %samaccountname%, noting the process ID, and then using keywords such as Begin Session: Logon, Milliseconds, loadProfile time: and unloadProfile time:.

Compare loadProfile time: with the total sign-in the user experienced. If profile loading is a small share of the wait, the storage is not your problem. Microsoft's sign-in guidance says that reviewing the virtual machine's performance is a great place to start, and its multi-session sizing table gives maximum users per vCPU of 6 for light, 4 for medium, 2 for heavy and 1 for power workloads. Cloud Cache needs more: Microsoft says to start with a ratio of two vCPUs to one user.

2. Separate network delay from service delay

In Azure Monitor, on the storage account's file service, chart Success E2E Latency and Success Server Latency with the Average aggregation. Server latency is the time spent inside Azure Files. The difference between the two is client-side time. Microsoft's own charts show about 0.17 ms of client-side latency when client and share are in one region, against 43.9 ms from an on-premises client.

Microsoft asks for the storage account to be in the same region as the session hosts, and in the same data centre location for optimal performance.

A connectivity test does not settle this. Test-NetConnection -ComputerName <server-fully-qualified-domain-name> -CommonTCPPort SMB shows name resolution and access to the SMB port. Microsoft warns that ping or Test-NetConnection results are not the same as transactional I/O and are bad indicators of how a storage provider will perform.

3. Look for throttling by response type

Use the Transactions metric and apply splitting on Response type. A throttled request often still succeeds, so a success-only availability view can look healthy.

Kerberos-authenticated traffic appears with a Kerberos prefix, so include those values in any filter. The metadata response types appear in the drop-down only if the activity occurred within the selected time range.

Metadata throttling calls for a different remedy from data throttling. Adding provisioned IOPS does not lift it, because the metadata limit applies regardless of the amount of provisioned IOPS a share has. Microsoft's options are to enable metadata caching on SSD shares, shard across multiple shares, or reduce the metadata load.

Diagnosing a stuck lock

A lock failure in the profile log looks like this, in Microsoft's published example:

[ERROR:000000a7] Operation 'AcquireExclusiveLock' failed. Retrying %x time(s) at %y second intervals (Unable to lock a region of a file.)
[INFO] ErrorCode set to 33 - Message: The process cannot access the file because another process has locked a portion of the file.

That wording proves another holder exists. It does not prove the holder is orphaned. The first holder to rule out is the user's own live session on another host. In the default configuration, that user gets a temporary profile if they do not sign out of the original session.

Follow this order.

1. Look for a live session. Microsoft's guidance is to verify the user has signed out of all sessions, using qwinsta or the Users tab in Task Manager on each candidate host.
2. Find who holds the file. The cmdlets need Az PowerShell 2.4 or later.

$sa = Get-AzStorageAccount -ResourceGroupName "<resource-group>" -Name "<storage-account>"
Get-AzStorageFileHandle -Context $sa.Context -ShareName "<share>" `
  -Path "<sid>_<username>/Profile_<username>.vhdx" |
  Sort-Object ClientIp,OpenTime

The output includes ClientIp, OpenTime, LastReconnectTime, SessionId and ClientName. ClientName and ClientIp tell you which host to inspect. The path above assumes the default folder name. If you set FlipFlopProfileDirectoryName to 1, as Microsoft's examples recommend for new deployments, the folder is <username>_<sid>, so use the name you actually see on the share.

3. Deal with that host first. If the session is gone but the disk is still attached, the cause lies on that host. Microsoft's CleanupInvalidSessions setting (HKLM\SOFTWARE\FSLogix\Apps, off by default) tells FSLogix to clean up after sessions that ended abruptly. Microsoft adds a reminder to prioritise environmental issues that solve the root cause rather than the symptom.
4. Assess recovery only after identifying the owner. A stale handle is a recovery decision, not proof that force closure is safe. Confirm that the session and process have ended, that no host is writing to the container, and that a recoverable profile copy exists. Record the exact share, file and handle identity before an authorised storage administrator follows the current vendor procedure.

Warning: Closing a handle on a container still attached and being written can lose data or corrupt the profile. File-wide or share-wide closure can affect other users. This article deliberately gives no executable force-close procedure because none was validated in a lab. On Windows file servers, the owner can inspect handles in Computer Management under Shared Folders, Open Files.

If locks keep recurring, check FSLogix's version before anything else. FSLogix 26.08, published 31 August 2026, fixed a condition where a locked or unresponsive container could block all sign-ins and sign-outs on a host until reboot, and a stuck storage provider hanging sign-out. Microsoft also requires customers to install and use the latest version. Then check antivirus. Microsoft publishes an exclusion list, and missing exclusions can produce sharing violations, temporary profiles and hangs at sign-out.

Settings that decide how failure feels

All are in HKLM\SOFTWARE\FSLogix\Profiles. Defaults are from the configuration reference. Recommended values are from Microsoft's standard configuration example.

The arithmetic matters. Twelve retries at five seconds is about 60 seconds of nominal waiting, and three at fifteen is about 45, before attempt time. The reattach defaults allow about 600 seconds, which keeps a frozen session waiting for ten minutes during a storage outage. Microsoft's example cuts that to about 45.

Microsoft says of temporary profiles that each organisation must decide the correct course: sometimes letting a user work on a temporary profile beats refusing them. The editorial recommendation for most business desktops is to refuse, using PreventLoginWithTempProfile and PreventLoginWithFailure, because the user otherwise produces work in a profile that will be discarded. With those set, Microsoft says the user sees a prompt to call support, and their only option is to sign out, so have a support route ready on the day.

Sizing the share

Size for four separate limits, not one. The figures below are Microsoft's published targets for classic shares.

Capacity. The default maximum container is 30,000 MB, and Microsoft's sizing page lists 30 GB as minimum profile storage for each workload type. Containers are dynamic, so use observed size on disk once you have a pilot. Microsoft advises alerting when the share has less than 20% free, because a full share leads to temporary profiles, hung sessions, and failed attach or detach. A container needs more than 200 MB free to attach.

Compaction runs at sign-out by default. It needs a dynamic disk and a defragsvc service that is not disabled, and it runs only when the file is over 1 GB and the reclaimable space is at least 20%. It adds work to the sign-out peak.

Performance. Microsoft's formula for SSD provisioned v2 recommends IOPS of MIN(MAX(3000 + CEILING(1 * GiB), 3000), 102400) and throughput of MIN(MAX(100 + CEILING(0.1 * GiB), 100), 10340) MiB/s. The burst limit is MIN(MAX(3 * ProvisionedIOPS, 10000), 102400), and it is credit-based and best effort.

A hypothetical worked example: 250 users at 30 GiB gives 7,500 GiB. The formula recommends 10,500 IOPS and 850 MiB/s, with a burst limit of 31,500 IOPS.

Treat that as the starting point. It is derived from capacity, and your load comes from behaviour. Do not take a per-user IOPS figure from a blog. Run a pilot, then read the peak of the Transactions metric during your real 8.30 am sign-in storm and work back to IOPS per signed-in user.

Microsoft's older comparison page recommends standard shares for light workloads under 200 users, premium or multiple standard shares for light workloads above that, and premium for medium, heavy and power workloads. That page predates provisioned v2, so check its tier names against today's offer.

Sharding. Multiple shares help if you hit a share-level limit, and they split the blast radius. Adding a second path to VHDLocations does not spread users, because when no container is found, one is created in the first listed location. Our reading of that setting, which is not a Microsoft sharding procedure, is that each group of hosts or users needs its own VHDLocations value, for example per host pool, and existing containers must be moved. The per-file limit is unaffected by sharding, but a single profile rarely approaches 12,000 IOPS on SSD. On HDD, 1,000 IOPS per file is a far more plausible ceiling for a heavy user.

What to choose and why

These are editorial recommendations.

For container format, use VHDX. Microsoft gives its supported size and reduced corruption scenarios as the reasons.

Risks and limits

Check Kerberos encryption on existing shares. Microsoft warns that from the April 2026 Windows Server update the default Kerberos encryption type changes from RC4 to AES-SHA1, and that file shares not upgraded may have access issues.

On Entra-joined hosts using Cloud Kerberos, the ticket lifetime is 10 hours. FSLogix 26.08 refreshes it in the background as a mitigation for sessions longer than that, so older agents are exposed on very long sessions.

Warning: SizeInMBs can be increased but not decreased, and an increase affects all users with dynamic disks where it is configured. Test it on a small group first.

Warning: Changing FlipFlopProfileDirectoryName on an existing environment changes the folder name FSLogix looks for, and users can end up with new profiles. Set it at build time only.

Warning: Do not set VHDXSectorSize unless Microsoft Support directs you to. Microsoft links a sector size mismatch to a stop error.

Warning: DeleteLocalProfileWhenVHDShouldApply removes existing local profiles. Microsoft says users must first have their data saved outside that profile.

Warning: Deleting content from inside a mounted container to reclaim space can cause data loss or profile corruption. Work on a copy where you can.

Limits move. Check the scale targets page on the day you design, and read which column applies: provisioned v2 and provisioned v1 differ. This article covers classic file shares, and no figures were measured for it.

Sources

Opened 10 November 2026. Sources behind the corrections reopened 10 November 2026.

• FSLogix prerequisites
• FSLogix configuration settings reference
• FSLogix configuration examples
• FSLogix release notes
• Concurrent and multiple connections
• VHD disk compaction
• Cloud Cache overview
• Logs and diagnostics
• Container locked
• Open file handles
• Container attach and detach
• Container size and space
• Long or failed sign-in
• Old, temporary or local profiles
• Storage FSLogix profile container
• FSLogix containers and Azure Files
• Azure Files scale targets
• Understand Azure Files billing
• Analyse Azure Files metrics
• SMB performance, multichannel and metadata caching
• Troubleshoot Azure Files performance
• Troubleshoot Azure Files SMB connectivity
• Get-AzStorageFileHandle
• Close-AzStorageFileHandle
• Session host virtual machine sizing guidelines

This article was originally published on 10 November 2026.