FSLogix Profile does not completely unload after a User logoff

[MarkF26]

The symptoms of the problem:

a) User attempts to login

b) Temp profile is created because FSLogfix could not load the profile

c) User logs off 

d) Task Manager still shows a stuck process under the "logged off" user.

e) Attempting to Kill the process results in "Access Denied" 

f) A Restart is the is the only way to release the hung process

g) Cleanup any leftover profiles in the \users folder 

h) User is then allowed to login and saved profile to load. 

FSLogix Event Logs:

1) Event ID: 26 [04/21/21 9:18:17]

   FindFile failed for path: <FSLogixProfiles share>\<userID-<sid>\Profile*.VHDX (The specified network name is no longer available.)

2) Event ID: 26 [04/21/21 9:18:17]

VirtualDiskAPI::CreateFormattedDisk failed to create vhd(x): <FSLogixProfiles share>\<userID-<sid>\Profile_<userID>.VHDX (The file exists.)

3) Event ID: 25 [04/21/21 9:18:17]

Profile load: Status: 0x9 Reason: 0x0 Error: 0x0 Username: <userID> SID: <sid>

4) Event ID: 26 [04/21/21 9:18:17]

LoadProfile failed. User: <userID>. SID: <sid>. (A device attached to the system is not functioning.)

5) Event ID: 26 [04/21/21 9:18:22]

Failed to restore credentials. Unable to decrypt value from BlobDpApi attribute (The specified file could not be decrypted.)

[not sure if the last event is related]

Possible Causes:

-Idle timeout disconnect and Logoff policy

[#2]

Not that this is the golden bullet but if you deny logon as temp profile it stops them logging on which in turn means a call to desk which typically involves them jumping on the share and killing the connection. If in azure file share the power shell to force close is usually enough. If shared from a file server I have found it can end up being a vm reboot as closing the open files on file server isn’t enough. I can’t say how it’s different just the findings

[#3]

I like the idea of the GPO item to deny login as temp, but the question is how to prevent it from happening in the first place.

[#4]

Given that MS have never fixed people logging into standard windows with temporary profiles I wouldn’t put all your eggs in that basket

[#5]

Update as of [05/06/21]:
It appears that the previous instance fixed itself. but ....
I have the exact reoccurrence [05/06/21]. The symptoms are exactly the same.
New possible Cuase;
- The FSLogix profile is an SMB share on a cluster volume. The Cluster Manager is showing some issues that I have yet to understand, and fix.
more info to follow as I learn more of what is going on.
--Action plan: get away from Cluster and move to Azure Storage account with AzureFile

[#6]

Did moving to Azure Files resolve your locked profile issues?

[#7]

@Jeff_Paulsen 

I have a few different instances around using both methods and get significantly less issues with the Azure files method than on a drive attached to a server, personally I think this maybe due to bandwidth limits of the VM that hosts the profiles and the bandwidth limits of Azure Files are generally a lot better and also there are less factors with this.

That being said the latest FSLogix update claims to resolve yet more of these issues and after doing the update before this one i have seen less issues still so it maybe you want to look at updating fslogix's on all AVD's first located here Microsoft/FSLogix Updates