Troubleshoot FSLogix Profile Mount Errors
FSLogix profiles can fail to attach for several different reasons. Generally, when a profile fails to mount, the end user should receive an error message and is unable to proceed to the desktop.
This guide should assist with troubleshooting these errors using Nerdio Manager. It has the following sections:
FSLogix Error Message Dialogue
Sometimes the FSLogix error is evident by the error message provided. For example, we can see the error describes the file is being used by another process.
Other times, the error may not be as descriptive, which requires gathering the actual log file to see more details.
Retrieve the FSLogix Profile Logs using Nerdio Manager
You can retrieve the FSLogix logs directly from Nerdio Manager.
To retrieve the FSLogix logs:
-
Review the error message and the computer name that is provided. For example:
In Nerdio Manager, locate the session host with the error.
From the action menu, select Request logs.
In the Request Logs pop-up, select FSLogix.
Select OK.
-
In the Host Pools Tasks section, wait for the Upload VM Logs to Storage Container task to complete.
Note: The VM must be online and accessible. This process may take up to 10 minutes to prepare the logs for download.
-
When the task completes, select Details and then select Download logs.
-
Extract the zip file and navigate to the folder ...\FSLogix\Logs\Profile.
Note: There can be multiple log files. The file names include the date. Open the one with the date that corresponds to the date when the error occurred, which is usually the most recent date.
-
Open the log file in a text editor.
Tip: Disabling word-wrap can help simplify searching and reviewing the logs.
-
Search the file for the text [ERROR. This helps you find the first error and the corresponding error code.
In this example, we can see the error fully, including the file path where the FSLogix profile is expected to be.
Common FSLogix Error Messages, Causes, and Solutions
This table shows some of the common FSLogix error messages along with their causes and solutions.
Note: If you don't see your error here, it may be a trailing error caused by the errors listed here. Try looking a couple of lines above the error you found. Often times the trailing error looks like this:
LoadProfile failed.... (An exception occurred in the service when handling the control request.)
Error |
Cause |
Solution |
---|---|---|
ERROR:00000005 ERROR:00000428 / Access is denied |
The user does not have permissions to access the file share. |
If using Azure Files, please check the RBAC/IAM Access Control in Azure and ensure the users are given Storage File Data SMB Share Contributor. Also check the SMB/NTFS permissions on the shared folder itself, and ensure that the user has access to the share. "Authenticated Users" contains users that have the SMB Share contributor role. "Administrators" has the SMB Share Elevated Contributor role. |
ERROR:00000020 / The process cannot access the file because it is being used by another process |
The VHDx or VHD profile file has a Read/Write lock, or file handle, already placed on it. Most likely another session is accessing the profile from another computer. |
Find the computer responsible and either manually log out the user session or restart the VM. If the user session is not active on any session host, closing the lock file handles from the storage account may be required. |
ERROR:0000048f / The device is not connected |
The file share's size limit/quota may have been reached. |
Increase the size quota for the file share. |
ERROR:00000020 / The user name or password is incorrect |
If this is a new Azure File Share, it is likely that the Storage Account hasn't fully synced/joined with Active Directory yet. The process can take up to 24 hrs in the worst cases. |
Wait for a few hours (can take up to 24 hours), then try again. If this is not a new Azure Files storage account, and it has been more than 24-48 hours since it has been joined to AD, you may need to contact Azure Support. |
ERROR:00000423 ERROR:00000043 / The network name cannot be found |
The FSLogix file path is misspelled/incorrect, or the session host cannot find it on the network using the file path (DNS failure or firewall blocks). |
Check your environment and Nerdio Manager settings.
|
ERROR:0x00000013 |
The FSLogix profile fails to attach due to the "Deny write access to fixed drives not protected by BitLocker" policy. This policy, enforced through Microsoft Intune, Microsoft Defender, or Group Policy Objects (GPOs), requires encryption on disks, and causes "The media is write protected" error. |
This issue can be resolved in different ways depending on whether the policy was enforced through Microsoft Intune, Microsoft Defender, or Group Policy Objects (GPOs). For details, see How can I resolve the FSLogix "Media is write protected" issue?. |
0x000004F1 The system cannot contact a domain controller to service the authentication request. |
While this could be an issue with the Session Host not being able to contact an Active Directory (or Entra Domain Services) Domain Controller, it is also possible to get the error from Entra ID joined environments. |
Domain Services: Check to make sure the Domain Controller is online and the VNet is configured to point to them in the DNS Settings. Entra ID: Review the Use Azure Files with Entra ID article How to Use Azure Files with Entra ID Joined Method for AVD and verify you have the following settings in place:
Note: If you needed to change any of these settings, it is recommended to re-image or redeploy your session hosts. |
Unknown status: 4294967295 |
This happens when a user logs in with a local profile and then tries to log in with an FSLogix profile. |
Ensure that the DeleteLocalProfileWhenVHDShouldApply setting is enabled in the FSLogix properties. See the Microsoft article Configuration Setting Reference for details. |
Manually Retrieve FSLogix Profile Logs
If you are using an older version of Nerdio Manager, or the functionality is somehow broken, you can attempt to manually retrieve the logs.
To manually retrieve FSLogix profile logs:
-
Connect to the desktop using the standalone AVD Remote Desktop Client in a full-screen session and wait until you see the error message.
Note: This can be done as the end user and does not require an admin user.
Press CTRL+SHIFT+ESC to open the Task Manager.
Navigate to File > Run new task.
Type explorer.exe and select OK.
-
Navigate to the path: %ProgramData%\FSLogix\Logs\Profile.
Note: The logs are located in this directory and named using the session host's system time and date stamp. If you haven't changed it, it is in UTC-0, so be aware of this when looking for older logs.
Manually Troubleshoot File Share Permissions
Using a session host, you can also attempt to troubleshoot possible File Share permissions issues. This is useful if you didn't use Nerdio Manager to create the file share, are using NetApp Files, or a self-managed File Server.
To manually troubleshoot File Share permissions:
Connect to the desktop using the standalone AVD Remote Desktop Client in a full-screen session and wait until you see the error message.
Press CTRL+SHIFT+ESC to open the Task Manager.
Navigate to File > Run new task.
Type explorer.exe and select OK.
Browse to the UNC specified in the Nerdio Manager Settings > Integrations page under the FSLogix file storage configuration. This is the file share path where the profiles are stored, also known as "VHDLocations."
-
If you are able to browse to the path, try creating a folder in that location. If unable to, then Share or NTFS permissions are incorrectly set.
Set Share permissions to Everyone or Authenticated Users - Full Control.
Set NTFS permissions per Microsoft guidance. See this Microsoft document for details.
-
If you are not able to browse to the path, then either the path, name resolution, or networking is incorrectly specified.
Verify that you can browse to the path from another computer.
-
Navigate to Task Manager > File> Run new task.
Type cmd.exe and select OK.
-
NSLookup or ping the host name and make sure it resolves and replies.
Note: Azure Files storage accounts do not respond to ICMP. This is okay.
If you are able to browse the path and create a file or folder, then verify that the user's profile VHD(X) file isn't locked by another session. By default, FSLogix profiles are configured to be exclusively locked by the first session that mounts the profile. If the user is actively connected to another host pool, then the profile is already locked. Concurrent access to profiles is supported by FSLogix but there are trade-offs to consider. See this Microsoft document for details.
Check the Environment
Often times FSLogix causes errors because the environment has not been fully configured and setup yet. If this is your first time deploying AVD or Nerdio Manager, it is very likely something hasn't been setup just yet. Ensure the following are in place:
If you are using Azure Files:
Tip: We recommend creating the storage account initially using the Nerdio Manager portal, which helps ensure all settings and permissions are correctly set.
In Nerdio Manager, navigate to Storage > Azure Files.
-
Check that there are no warning icons. For example:
-
If the storage account is AD-joined and synced, in the Azure portal, make sure the storage account looks like this:
-
In the Azure portal, make sure that Users/Groups have been given permissions to the File Share within the Storage account. (Role: Storage File Data SMB Share Contributor)
-
You can quickly navigate to the Storage account in Azure if you linked it with Nerdio Manager.
-
Navigate to the Access Control (IAM) section, then select Role assignments.
-
Scroll down the assignments list until you reach here. Make sure the users/groups have the role.
-
The session hosts have been created after a valid FSLogix profile network storage path has been configured in Nerdio Manager. Changes to FSLogix settings within Nerdio Manager are not retroactive (unless you select Apply to existing session hosts), and are only applied when new session hosts are created.
If you are using Azure NetApp Files:
Ensure the ANF volume was provisioned correctly and there are no errors reaching and joining the domain.
Check the file share permissions within Windows. There are no share-level or file-level permissions accessible for ANF from the Azure Portal.
ANF storage accounts should resolve and respond to ICMP, so ping testing should be successful, by default.
If you are using a self-managed File Server:
Ensure there is network connectivity between the file server and session host VMs. Check Network/OS Firewalls, Azure Network Security Groups, and VNet configurations/peerings.
Check the file share permissions.
Comments (0 comments)