Announcing General Availability of FSLogix 2201 (2.9.8111.53415)

[Steve Downs]

Today we are announcing the General Availability of FSLogix 2201. Updates include improvements to login and logoff times, cloud cache performance improvements, and 30+ accessibility updates.

Download Location
https://aka.ms/fslogix_download

Installation notes
This release can be installed over previous versions of FSLogix.
Installation Instructions: Install FSLogix Agent - FSLogix | Microsoft Docs

Changes
• Fixed issue where the FSLogix Profile Service would crash if it was unable to communicate with the FSLogix Cloud Cache Service.
• The OfficeFileCache folder located at %LOCALAPPDATA%\Microsoft\Office\16.0\OfficeFileCache is now machine specific and encrypted so we exclude it from FSLogix containers. Office files located outside this folder are not impacted by this update.
• Windows Server 2019 version 1809, and newer versions of Windows Server, natively support per-user search indexes and we recommend you leverage that native search index capability. FSLogix Search Indexing is no longer available on those versions of Windows Server.
• Windows 10 Enterprise Multi-session and Windows 11 Enterprise Multi-session natively support per-user search indexes and FSLogix Search Indexing is no longer available on those operating systems.
• FSLogix now correctly handles cases where the Windows Profile Service refCount registry value is set to an unexpected value.
• Over 30 accessibility related updates have been made to the FSLogix installer and App Rules Editor.
• A Windows event now records when a machine locks a container disk with a message that looks like "This machine '[HOSTNAME]' is using [USERNAME]'s (SID=[USER SID]) profile disk. VHD(x): [FILENAME]."  This event is generated from the METADATA file created in the user's profile directory. This file can be ignored, but not deleted.
• Resolved an issue where the DeleteLocalProfileWhenVHDShouldApply registry setting was ignored in some cases.
• Fixed an issue where active user session settings where not retained if the FSLogix service was restarted. This was causing some logoffs to fail.
• Fixed an issue where FSLogix did not properly handle logoff events if Profile or ODFC containers were disabled during the session or per-user/per-group filters were applied mid-session that excluded the user from the feature. Now FSLogix logoff related events will always occur based off the FSLogix settings applied at login.
• FSLogix will no longer attempt to reattach a container disk when the user session is locked.
• Fixed an issue that caused the FSLogix service to crash when reattaching container disks.
• Fixed a Cloud Cache issue that caused IO failures if the session host's storage block size was smaller than a cloud provider's block size. For optimal performance, we recommend the session host disk hosting the CCD proxy directory has a physical block size greater than or equal to the CCD storage provider with the largest block size.
• Fixed a Cloud Cache issue where a timed out read request (network outage, storage outage, etc.) was not handled properly and would eventually fail.
• Reduced the chance for a Cloud Cache container disk corruption if a provider is experiencing connection issues.
• Resolved an issue where temporary rule files were not deleted if rule compilation failed.
• Previously, the Application masking folder was only created for the user who ran the installer. With this update, the rules folder is created when the Rules editor is launched.
• Resolved an interoperability issue with large OneDrive file downloads that was causing some operations to fail.
• Fixed an issue where per-user and per-group settings did not apply if the Profile or ODFC container was not enabled for all users.
• Resolved an issue where the Office container session configuration was not cleaned up if a profile fails to load.
• Fixed an issue where HKCU App Masking rules leveraging wildcards would fail to apply.
• Fixed an issue that caused some sessions configured with an ODFC container to fail to login.
• Resolved an issue where the App Rules editor would crash if no assignments were configured.

Resources
FSLogix documentation: https://aka.ms/fslogix
Download Location: https://aka.ms/fslogix_download

[#2]

a review of the FSLogix configuration is currently being carried out. But that's pointless

[#3]

Please keep us informed, thank you.

[#4]

One correction to my first post where I wrote it works when user is not excluded. I re-tested it and found out same buggy behavior.
Post updated:
https://techcommunity.microsoft.com/t5/azure-virtual-desktop/announcing-general-availability-of-fslo...

[#5]

@ExSportCZ 

Microsoft Support has confirmed this Behavior as an Error of this Release. Still waiting for a Solution.

[#6]

Curious as to what antivirus people are running. We are using Crowdstrike and it appears this may be what could be causing profile folders to be left behind at logoff. We’ve built a new image without crowdstrike and so far haven’t seen any issues.

[#7]

Kasperskiy, Windows Defender.

https://docs.microsoft.com/en-us/azure/architecture/example-scenario/wvd/windows-virtual-desktop-fsl...

In the latest version of FSLogix, I don't run into any problems. Only the problem of local_%user% folders hanging remains.

[#8]

I’m waiting for HF1 realize - expected next month. Hopefully it will help and will resolve some issues.

[#9]

Where did this information come from?

[#10]

Dear Mirtelo, have you heard anything of the support? Starting to get crazy with this issue.

[#11]

2201 HF1 does not resolve the Error.
MS Support is still in discussion with Product Group.

[#12]

For me it took half year to get fix and I was very lucky as 1st estimation from FSLogix Teams to get fix was 1 year!

Issue: multiple OS crashes daily.

It’s very difficult to deal with such support. Hopefully it will change in the future… if not than it’s really risky product to use.

[#13]

We have started seeing user folders being left behind at logoff.

Not the local_ folders but the %username% folders.

This is on this build and after everything being stable for months.

Isnt affectting all users

Checking event viewer shows the profile was not unloaded - "check the VHd was detached" 

Confirmed VHD is not attached and no active redirects.

Handle etc. Shows system pid 4 is locking the VHD.

No way to unlock the VHD or delete/remove it as system has it open after user signs out. 

Only solution apart from rebooting the entire server is to temporarily exclude the user from Fslogix Profile using built in group to get the user logged in, then rebooting out of hours. 

Azure suport ticket is open. 

Its funny we had no issues for a few months, nothing changed apart from Cumulative updates on windows 10 21H2 multisession. 

Profile issues are back for us, av exclusions are correct.

Something with pid 4 is locking our VHDX files and also preventing them from being dismounted properly, but the session hosts do not see the VHDX files as attached. 

Any ideas?

[#14]

Sounds similar to the issues we’ve been seeing for the last few months. I put In a support ticket about 3 weeks ago to Microsoft and haven’t heard a thing back about it.  Mostly ours is the local profile left but we have had instances of the username folder left and that stops the user from logging in to that machine again due to profile unable to load message at logon.  Like you said the only solution appears to be a machine reboot.  We are still performing nightly checks across 16 machines and rebooting any with leftover profiles.  We are also supposed to be building another 70 machines in another region and that work is on hold as performing checks on 16 servers is bad enough for our ops guys but asking them to check another 70 is not a valid solution 

[#15]

Hello. This problem has always existed. The developers claim they can't fix it.

[#16]

I don't know if you got an answer yet, but i've found an fix (temporarily) for my situation.
In my case i had a programm (DATEV) which stored the administrator credentials for some update stuff (autologin etc.) the programm then created 2 tasks that would start some processes right before the login. When these tasks got executed, the whole blackscreen problem appears.

So basically i removed the whole creditial stuff out of the software and disabled the tasks that would bring up the processes.

Guess they changed something in the whole user profile buildup.

[#17]

We have been good for a couple of weeks.

Turns out that even if you are not actively using Windows Defender on an Azure VM, it is still "Active" to some extent.

Use below to add exclusions to Windows defender (even if you are running another AV):

# Defender Exclusions for FSLogix
$Cloudcache = $false # Set for true if using cloud cache
$StorageAcct = "Storage Account Name" # Storage Account Name
$Share = "File Share"
 
$filelist = `
"%ProgramFiles%\FSLogix\Apps\frxdrv.sys", `
"%ProgramFiles%\FSLogix\Apps\frxdrvvt.sys", `
"%ProgramFiles%\FSLogix\Apps\frxccd.sys", `
"%TEMP%\*.VHD", `
"%TEMP%\*.VHDX", `
"%Windir%\TEMP\*.VHD", `
"%Windir%\TEMP\*.VHDX", `
"\\$Storageacct.file.core.windows.net\$Share\*\*.VHD", `
"\\$Storageacct.file.core.windows.net\$Share\*\*.VHDX"
 
$processlist = `
"%ProgramFiles%\FSLogix\Apps\frxccd.exe", `
"%ProgramFiles%\FSLogix\Apps\frxccds.exe", `
"%ProgramFiles%\FSLogix\Apps\frxsvc.exe"
 
Foreach($item in $filelist){
Add-MpPreference -ExclusionPath $item}
Foreach($item in $processlist){
Add-MpPreference -ExclusionProcess $item}
 
If ($Cloudcache){
Add-MpPreference -ExclusionPath "%ProgramData%\FSLogix\Cache\*.VHD"
Add-MpPreference -ExclusionPath "%ProgramData%\FSLogix\Cache\*.VHDX"
Add-MpPreference -ExclusionPath "%ProgramData%\FSLogix\Proxy\*.VHD"
Add-MpPreference -ExclusionPath "%ProgramData%\FSLogix\Proxy\*.VHDX"}

This will stop Defender interacting with VHD etc. 

Also, look up autoendtasks registry key and apply to your VMs/images - helps with making sure nothing hangs up the profile unload process on user logoff.

After implementing the above we have been okay for a little while with the single user who was affected. 

Too early to call it resolved but so far so good. 

[#18]

@Thor92 
If you read my description what is happening in the background you should imagine why such behavior.
The root issue is FSLOGIX don't handle user sessions/processes impersonated from other user sessions (or anytime more sessions with different ID is opened for same user).
If there isn't existing user profile loaded already (handled by FSLOGIX), new background process is loaded with "default network profile". Now when "real/full RDP/RemoteApp" session is loaded, new session is created with different sessionID (handled by FSLOGIX so previous profile is unloaded). Such behavior will broke whole profile functionality that everything will broke (in the new session explorer process crash endlessly, etc...).

In some cases, when it happens, it can be fixed by session host restart but not always it helps as sometimes some fragments will stay in config on session host or in profile so restart will not help either.
Other times it is enough to delete profile so it is recreated but if session host is "broken", user is able to login to the other host but not to the one where such issue with double sessions occurred (issues with import/export registry, etc...).
The good news is MS fixed these broken states which can happen to session hosts or profiles.
Right now fix is in internal/private version only so hopefully will be released publicly soon.
Still there are some other bugs not fixed but great it stopped corrupting session hosts or profiles itself :)

[#19]

@ExSportCZ, Do you know if there is any news about fixing the local_%username% folders hang?

[#20]

Would also like to know about any fix for the local_username left behind after logoff.

[#21]

Sorry don't have any info about it. I spotted such behavior that sometimes it is not cleared for many different reasons but as this folder is temporary and when there is a conflict, another one is created, it should not be the big issue, right?
Anyway as I mentioned I spotted such behavior too. In my case the folder wasn't deleted because there was a lock by SYSTEM and user account not releasing this local_* or profile folder itself (btw. I don't use any redirections.xml, only TMP/TEMP/IE CACHE folders "excluded" via FSLOGIX GPO).
Try to check locks by e.g. command ".\handle64.exe -u -a affected_username" which will show you any locks present in the system. I had to restart few services (represented by PID in the output) to unlock the folder so was able to delete it manually without session host restart.
Not always it must be locked by any processes so maybe during the logoff process some asynchronous process is not handled correctly by FSLOGIX so it tries to delete folder too early, when it is still "locked", so it will fail but later when async process finish, folder is not handled by FSLOGIX anymore so must be deleted manually. MS mentions it is "lazily" deleted so maybe it means it can be there for years after logoff in some cases :)