Submit a request

Nerdio Help Center

FSLogix Profile VHD File Handles

Applies to: Nerdio Manager for MSP (NMM) 

Version : 2.0.0 and greater

Disclaimer : Nerdio Manager for MSP is an automation and management solution. NMM Partners are responsible for understanding, and managing Microsoft Identity Services, M365 and Azure Resources. For Identity and Azure support, please contact your Distributor or Microsoft directly.


By default, FSLogix profiles can only be accessed by one machine/user session at a time. When a user attempts to log into a machine while the VHDx file has a file lock/handle on it, by default FSLogix will refuse to serve the user a session and present a black screen. The error will be something like this: ERROR:00000020 / The process cannot access the file because it is being used by another process


Common Causes

The file handle error can be caused by a few different reasons. Most often it is caused by the following scenarios.


Scenario 1: The User is assigned to Multiple Host pools which use the same storage account.

While assigning users to more than one hostpool is supported, a single user having multiple sessions across hostpools which attach to the same FSLogix profile VHDx is not. (For instance, if hostpool A and hostpool B both have the same file path set for VHDLocations.) In this case, User "Bob" already logged into a session within Hostpool B, then either disconnected (didn't fully log out) or is actively using the session. Bob then tries to connect to a new session for Hostpool A. Bob cannot connect successfully because the session from Hostpool B is already using his profile.



To avoid this, it is recommended to either only assign users to a single hostpool each, or create separate storage accounts for each host pool. If the latter is used, keep in mind the user profiles will be separate, and will NOT be synchronized. The user's profile will be confined to each hostpool.


Scenario 2: A stuck/"ghost" session is locking the profile

Sometimes the AVD Agent on a session host can become unresponsive. This will cause the AVD Management service to be unaware of the existence of sessions on the session host. When the User "Bob" in this example tries to log into AVD, the AVD service assumes this is a new session and directs them to connect to session host A, unknowing that there is already a old session from the user which is holding on to the user's profile.



Because the AVD service is unaware of the session, looking up the user's session from either Nerdio or the Azure portal will provide no results of existing sessions, meaning either the offending machine must be connected to and the user's session manually logged or, or for the entire VM to be shutdown/restarted.


It is recommended to use auto-scale's "Auto-Heal" functionality to prevent unresponsive hosts from staying stuck. 



Scenario 3: A User previously logged in to a session host (with FSLogix enabled) directly using traditional remote desktop connection (not AVD)

This situation is common for admin users who use remote desktop to "jumpbox" or directly connect to session hosts.

FSLogix is used for other VDI solutions aside from AVD (Citrix, VMware..etc). As such, FSLogix treats all RDP-based connections the same. Due to this, RDP will cause an FSlogix profile to be attached. However, since the traditional remote desktop connection is not using the AVD management broker, the AVD service is unaware of this session. So when Bob tries to log in, it will assume no sessions are active and it is safe to send bob to a new session host.



If there is a need to use RDP connections for management and troubleshooting purposes, and a consistent profile isn't required, it is recommended to add the admin users to the "FSLogix Profile Exclude List" local group. Here is a command that can be used with Scripted Actions - Windows Scripts to add users to hosts, or run on the Image VM:

Add-LocalGroupMember -Group "FSLogix Profile Exclude List" -Member "<Domain Group or User UPN>"

Be sure to replace <Domain Group or User UPN> with the group or username before running this script.




Find the IP of the Machine responsible for the File handle

Generally, file handles hold information about the source of the file lock. With all methods below, finding the IP of the machine is possible. Then from there, referencing against VM information or IP address tables will pinpoint the culprit computer.


It is important to note that while you can attempt to close the file handles using these various tools, in most cases the FSLogix service in the session causing the lock will attempt to re-establish the connection, causing the file to be locked again. 


Finding the IP for Azure Files Storage Accounts:

There are three methods to view file handles for Azure Files storage accounts:

Method One - Using Nerdio Manager (Recommended)

Go to Storage -> Azure Files. Find the Storage account used for FSLogix. Then go to the action menu and select "File Handles". 

Type in the username that is used in the profile path. This search queries the VHD profile file path, so be mindful that using the full UPN of a username, i.e. "", will NOT yield results. Try using just the SAM Account name, i.e. "jsmith" (depending on your naming scheme).


We can also attempt to close the file handle here, however as described above, this most times will not fix the issue.

Method Two - Using Azure Powershell Directly

If NMW is not a new enough version, or is unavailable to you, you can find the file handles using the Azure Powershell modules. The Get-AzStorageFileHandle cmdlet (Requires Az Module) can provide the necessary information. 


We have provided a helpful script which uses this command. Change the file from .txt to .ps1 and run on a system which can connect to the storage account, such as a session host, and has the Az powershell module installed.

Note: Nerdio is not responsible for misuse of this script, please run at your own discretion.

Download it here

Was this article helpful?
0 out of 0 found this helpful
Important Notification for NFA Partners Only
  • Microsoft is sunsetting Azure Classic (not Azure Virtual Desktop (AVD)) - Microsoft Article
  • NFA sunset occurs February 20th, 2023
  • NFA will be fully supported until the official sunset -


Article is closed for comments.