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
Apr 08 2022 12:10 AM - edited Apr 08 2022 12:11 AM
@Ryand32 I cant find the concurrent connections setting. I screenhot the the CloudCache policies.
Apr 08 2022 08:18 AM
@kesslerseb I've asked Microsoft for a response on this a few months back and never received a response if this has been removed, the thing is this a requirement for alot of VDI deployments with Cloud Cache so until this is available in the admx template of the new version, I will stick with the older version. https://docs.microsoft.com/en-us/fslogix/whats-new#fslogix-apps-release-2004-29734930108
Apr 08 2022 08:37 AM
Apr 08 2022 10:23 AM
Apr 26 2022 05:03 AM
We encountered the same Problems with AVD. After Update i get a Black Screen for one Administrator Account. Ohter Domain Admins work very well. Domain Users don´t have any Problems. All Admin Accounts are in one Group and this Group is placed in FSLogix Exclude Group.
Apr 26 2022 09:16 PM
Apr 27 2022 12:47 AM - edited Apr 27 2022 10:40 PM
W2019_x64 FSLogix with 2.9.8111.53415
If a process is started with the user's credentials before the actual login, the login via console or RDP session no longer works (black screen). It looks as if MS has intervened in the User Profile Service with the update and prevented the merging of the two profiles.
Apr 27 2022 02:50 AM
@mirtelo @kesslerseb
That sounds to me like a topic that goes in the direction of "ConcurrentUserSessions".
Apr 27 2022 03:38 PM - edited Apr 27 2022 04:22 PM
@Steve Downs The issue with leaving the local_username even exists with a basic avd image in azure with fslogix installed as we had the same issue today. Surely this issue needs to be fixed? The fslogix cache folder also leaves behind empty user profile folders most of the time at logoff. Do we have any eta on when these logoff issues will be resolved?
Apr 28 2022 12:23 PM
Apr 28 2022 01:02 PM
May 02 2022 04:09 AM - edited May 03 2022 08:33 AM
Hello@Jason_Parker
You are wrong. It is definitely FSLOGIX related.
How to reproduce it (PROFILE container used only, with fSingleSessionPerUser=1) :
- Use [FSLogix Profile Exclude List] to ignore some specific users.
- Start RemoteApp with such user via published app which loads first RemoteAPP session on one RDSH.
- Start Full RDP to the same RDSH for second session.
FSLOGIX writes in the log it ignores this account (no VHDX is loaded, "Not a session we care about" in the log) but it is not completely true as IT UNLOADS USER HIVE from REGISTRY! This will corrupt both user sessions and as the profile/user hive is not correctly cleared from registry, until the server restart (or manual registry "hacks") user is unable to logon correctly (broken desktop for admin or "The Group Policy Client Service failed the sign-in. Access is denied." for non-admin user what means forced log-off).
And yes, it is FSLOGIX related as when [FSLogix Apps Services] is stopped (no need to uninstall it), magically there is no issues to open "two" sessions on the same server, no corruptions.
It is very easily reproduceable, happens every time.
Thanks for your time.
Edit: Now I spotted you reacted to other comments, about "local_username" and not broken sessions others mentioned, sorry for that, but the question/bug remains
Edit2: And forgot to say, when user is not excluded so user profile is loaded via FSLOGIX (mounted VHDX file), no corruption occurs when two sessions are loaded on the same server. Weird, right?
EDIT3: Nothing weird, edit2 is wrong as it doesn't work same way like excluded users. I re-tested it and spotted the same buggy behavior so last time when I tested it I mixed results or some inattention...
May 02 2022 05:49 AM
May 02 2022 05:59 AM
May 02 2022 06:10 AM - edited May 02 2022 11:46 PM
@mirtelo Thanks for your info and created MS case.
Such answer, when it is clearly stated it works when FSlogix service is stopped/uninstalled but will break when service is running, it is typical support response :) Limited FSLOGIX log is clean what means it is not related:)
Ok, will give it additional time by creating support tool log and check what it is inside...
May 02 2022 09:53 AM - edited May 02 2022 11:47 PM
As the session is broken, it is not possible to get logs via support tool from this user session as it generates empty ZIP file.
Getting it under different user creates logs but nothing useful there.
Process Monitor clearly shows that USER hive is unloaded by frxsvc.exe process, for user account [fslogixbug] which should be excluded.
The proof that fslogix unloaded actually loaded user session can be seen in attached picture, which leads to explorer crash etc...
https://photos.app.goo.gl/Y4Vod29R9aiPjjH19
Btw. it is not needed to open RemoteApp and then FullRDP session. It was enough to open e.g. Notepad process under different user by "Start-Process Notepad.exe -Credential $creds" ($creds = fslogixbug creds) which opened process under existing session ID 2. Logging to FullRDP creates another new session ID 4 and will crash completely due to FSLOGIX buggy logic :)
Thanks anyone involved in this issue.
May 02 2022 10:32 AM
May 02 2022 09:00 PM
May 03 2022 12:21 AM
@steveturnbull1975 Not always true that it is installed but not running so it is not related.
Similarly like Antivirus, FSLOGIX loads filter driver which is "active" also in case FSLOGIX services are stopped. So if there is some bug in filter driver, it can affect system stability or its correct functionality.
Try to stop FSLOGIX services and run command "fltmc instances". You will see [frxccd] and [frxdrv] is active also in case no running services of FSLOGIX.
Similar issue I described above, where FSLOGIX should not manipulate with user sessions excluded from FSLOGIX logic, but it is not true as fslogix writes into the log it ignores it but unloads user hives from registry for user active sessions which broke them completely.
May 03 2022 12:34 AM
And still MS support ignores you? It is easily reproducible, there is evidence fslogix unloads user hive when it should ignore such sessions, there is an evidence fslogix logging mechanism doesn't log this unload action so using arguments like log is clear, not our fault is...no-comment...
When companies pay for MS technical support but MS technical support ignores the evidence...don't know what to say