Mar 29 2022 12:36 PM - last edited on Apr 14 2022 11:02 AM by Eva Seydl
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
May 03 2022 12:57 AM
May 03 2022 02:12 AM
May 03 2022 08:36 AM
May 12 2022 09:11 PM
Microsoft Support has confirmed this Behavior as an Error of this Release. Still waiting for a Solution.
May 26 2022 02:56 PM
May 26 2022 11:46 PM
May 27 2022 02:23 AM
I’m waiting for HF1 realize - expected next month. Hopefully it will help and will resolve some issues.
May 27 2022 05:56 AM
Jun 01 2022 05:45 AM
Jun 01 2022 10:38 PM
Jun 02 2022 12:23 AM
Jun 28 2022 01:25 PM
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?
Jun 28 2022 03:33 PM - edited Jun 28 2022 03:38 PM
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
Jun 28 2022 11:28 PM
Jul 07 2022 08:54 AM
Jul 07 2022 01:01 PM - edited Jul 07 2022 01:34 PM
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.
Jul 11 2022 08:19 AM
@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 :)
Jul 12 2022 12:58 AM
Jul 12 2022 01:01 AM
Jul 12 2022 04:28 AM