Announcing General Availability of FSLogix 2201 (2.9.8111.53415)

Microsoft

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

76 Replies

@Ryand32 I cant find the concurrent connections setting. I screenhot the the CloudCache policies. 

@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

@Ryand32 can you clarify why you need concurrent connections with Cloud Cache? The two things are not related and you're actually missing out on significant improvements to Cloud Cache by not upgrading - and exposing yourself to a security vulnerability that we patched in cloud cache.

Concurrent connections only apply to a niche scenario where a single user must be able to have multiple WINDOWS sessions simultaneously on the same session host. Most customers do not need or want the same customer to have multiple Windows sessions on the same VM. They might allow multiple Citrix or VMware sessions - but all those sessions, by default, share a single Windows session.

That said, we only removed the concurrent setting from FSLogix because the setting is already available as an RDS policy. If you wish to allow users to launch multiple sessions then you'll find the setting in "Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections". From there, set "Restrict Remote Desktop Services user to a single Remote Desktop Services session" to "Disabled".

@kesslerseb 

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. 

Hi Steve, but there is a Problem in the new Release wich results in a BlackScreen at Login. I will try to explain it: We have a User, SoftwareAdmin. This User is Member of LocalAdmin Group and Member of FSLogix Profile Exclude List Group. This User generates a Sheduled Task at the System, this Task starts a Process at Systemstart in the Context of the User SoftwareAdmin. With the new Version in Place it is no longer possilbe to Logon with the User SoftwareAdmin.

W2019_x64 FSLogix with 2.9.8111.53415

@Steve Downs 

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.

 

@mirtelo @kesslerseb
That sounds to me like a topic that goes in the direction of "ConcurrentUserSessions".

@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?

Hi @steveturnbull1975 - we have heard anecdotal comments about these issues, but we lack data and evidence that these issues are directly related to FSLogix. Please ensure you have opened a support ticket so that our team and troubleshoot and triage it effectively. If you have an open case, please send me the case in a DM.
@mirtelo I am not sure I follow this sequence of events.

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 :smile:

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?:cool:

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... :cool: 

Thanks for the detailed implementation. We opened a case at MS
Answer from MS Support:

As you saw in the data you extracted with the FSLogix Support Tool, there are no errors from FSLogix's side that could indicate this is being caused.

@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...

 

 

 

 

 

 

 

 

 

 

 

@mirtelo 

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.

We’ve been having issues with user profile service failed the logon, profile service cannot be loaded. I thought this was only on our onprem 2k19 but we have also been seeing it on a really basic AVD build which has fslogix installed but not enabled. If it’s not enabled maybe it’s not an fslogix issue and some problem with multi user windows OS in general. Possibly related to some recent patching. The promise of fslogix being the saviour of all things profile is great when it works but I’m not so sure about it’s reliability with all these random issues
@ExSportCZ
This is what i also saw in procmon. We startet notepad via Sheduled Task at System Boot.

@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. :unamused:

@mirtelo 

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 :smile: