I dealt with an interesting support issue recently that turned out to be an extremely simple fix, but the culprit took couple of hours to find, so I thought I’d share it. I also wanted to share this so people (hopefully) aren’t so quick to blame FSLogix for anything related to profile issues with AVD. Sometimes FSLogix doesn’t want to play nice, but generally, if your configuration follows best practices, it works very well. In the vast majority of cases, temporary profiles are usually caused by one of the following:
- A lock on the user’s VHD due to another session (or hung session) on a different session host
- Permissions being improperly set
- User not being part of the correct security groups, which usually ends up being permissions.
The aforementioned reasons have numerous blogs and troubleshooting guides written already. Those should be the first things you are checking if you’re dealing with a user receiving a temporary profile. However, this issue was unique for me, and was only happening to a few users who were recently onboarded. They were all receiving the below error despite being in the correct groups, permissions being OK, and verifying their profiles were not locked.
Shortly after I started working on this I realized none of the affected users had proper licenses assigned for AVD. After assigning them licenses and waiting a couple of hours, the problems still persisted. I also noticed corrupt VHDX files in their FSLogix directories. Deleting and recreating their FSLogix profiles resulted in the same issue. After double checking that permissions and security groups were correct, I started looking at logs and doing some troubleshooting:
We can see the host we are signed into has the profile locked, as expected. But we are still getting a local temp profile.
But FSLogix shows this signed-in account is not using an FSLogix profile:
And we can see this account is using Local_TEMP as the local profile:
But… the VHDX is mounted:
Looking in FSLogix logs shows everything OK so far:
But then we get some weird entries that no profile is detected and the UsrClass.dat file wasn’t found:
And then showed the temp profile directory being used:
And Lastly, showing us this user is assigned a temporary profile:
At this point, it does not appear to be an FSLogix issue. I started looking at the OS level even though this was happening on all session hosts for these users. If we look at the registry profile list, we can see the issues here. This user shows TEMP as their local profile, and the centralprofile is a network location where they don’t have access:
Compared to a user who is functioning fine. We can see there is no value for CentralProfile and their FSL_OriginalProfileImagePath and ProfileImagePath values point to the c:\users location followed by their username. Something seemed fishy that the affected users had a centralprofile value, but I couldn’t determine why (yet):
I tried adding that user to the FSLogix profile exclusion list. They received a standard local profile without issues. Then, I changed the registry values accordingly while deleting the central profile value, and then signing back in, but the issue persisted, and the registry values came back with the problematic values.
At this point, I still felt like this had to be a permission issue, but the users had the correct permissions to the FSLogix location and the c:\users directory. I started digging into more logs and went through all the steps here –Troubleshoot user profiles with events | Microsoft Learn. But, I still couldn’t find anything pointing to the issue. I kept focusing on the hosts and permissions, but after copying one of the affected user accounts and trying with a new test account, I had the same problem. Because of that, I started comparing AD attributes between the affected users and users who were working properly. That’s when I found the problematic AD attribute, which matched the CentralProfile registry value. We can see in the image below, this value is not set on the left for users who are functioning properly:
This value is part of the profile tab:
Removing that attribute’s value resolved the issues. Now we understand why FSLogix was creating a VHDX for the user, but when trying to load the user’s hive from UsrClass.dat, it was reporting that it didn’t exist, since it was looking in a network location where no profile existed. The attributes from AD were overriding the FSLogix configuration and creating registry entries for the user profile to point to \\server\share\username, which contained no profile data.
After determining the cause, it turns out that when the user was onboarded, either an old disabled account was copied, or someone used an old document and set that attribute, resulting in the profile path attribute being set. So, make sure your onboarding processes are accurate and up-to-date before blaming AVD and FSLogix 🙂