none
Release notes for FSLogix Apps 1909 HF_01 (2.9.7237.48865) - HOTFIX RRS feed

All replies

  • This release seems to be buggy. After the installation of 1909 HF_01 the user login takes 5-10 minutes and users receive black screens.

    After revert to version 2.9.7205.27375 all login issues are gone.

    • Edited by ASDF_FDSA Sunday, November 24, 2019 8:32 PM
    Sunday, November 24, 2019 8:10 PM
  • We are glad to see this hotfix marked as ready for production. sharepoint data corruption was a big issue here.

    @asdf_fdsa We see the the black screen issue on2.9.7205.27375 with Onedrive systemwide installer 19.152.0927/19.174.0902 as well. 

    Monday, November 25, 2019 7:36 AM
  • This issue where login takes 5-25 minutes is also present in Version 2.9.7117. The issue started from one day to the other. It also happens on different installations in different customer szenarios!

    Monday, November 25, 2019 8:01 AM
  • In our environment the issue with long login times started last week. Also from one day to the other.

    We run 2.9.7205.27375. Seems that the hotfix release is not fixing this issue.

    We also use the systemwide installation of OneDrive (19.174.0902). Anyone tried a newer version?

    Monday, November 25, 2019 8:30 AM
  • do you still have the logon issue? or did you fixed it with a workarround?
    Monday, November 25, 2019 9:12 AM
  • This started happening to us on Friday and is now spreading around our organisation,

    Same systemwide installer used, we saw the problem on fslogix 2.9.7117.27413 and 2.9.7205.27375, have not tried this hotfix but sounds like it has the issue too.

    I'm going to be guessing this is due to OneDrive auto updating.

    I've tried getting in touch with fslogix support but since the changes it looks like Microsoft may not have attached our support information to any of our email accounts and I can't find anywhere else to contact to fix that, so I've made a call into our generic office 365 support on Friday, but no progress yet.

    Pretty much causing havoc in our organisation as users can change computers 5 or more times per day.

    Monday, November 25, 2019 9:46 AM
  • We've tried uninstalling / reinstalling the OneDrive systemwide client.

    The logon delay was also present while the OneDrive client was not installed on the machine.

    Is everyone else with the issue also getting a similar message in the application event log?

    The winlogon notification subscriber [frxsvc] took 242 second(s) to handle the notification event (StartShell)

    Monday, November 25, 2019 10:43 AM
  • We've tried uninstalling / reinstalling the OneDrive systemwide client.

    The logon delay was also present while the OneDrive client was not installed on the machine.

    Is everyone else with the issue also getting a similar message in the application event log?

    The winlogon notification subscriber [frxsvc] took 242 second(s) to handle the notification event (StartShell)

    Yes, our delay is about 740 seconds. We do not use OneDrive on affected rds servers.
    Monday, November 25, 2019 10:53 AM
  • Started also on Friday (strange similarity)

    OneDrive per user install.

    FSlogix version 2.9.7205.27375 already more than a month in production.

    latest vDisk release was 15/11, so looks like no link there

    vDisk update only contains monthly hotfixes.

    Extra info: we use Windows Defender on our 2016 XenApp workers.


    Monday, November 25, 2019 11:24 AM
  • My collegue may found the solution: Windows Defender started scanning attached vhd´s on friday 22nd of nov. If you disable Windows Defender Realtime via Powershell Command "Set-MpPreference -DisableRealtimeMonitoring $true" Login Times are great again!

    I hope this works also for you.

    Monday, November 25, 2019 11:50 AM
  • Thanks, yep, I was just returning from some testing and about to post the same thing!

    Now to work out what to do about this and to see if I can get any agreement here to accept antivirus being turned off as a solution...

    Everything is already excluded so I don't think there is any other option until this is fixed.

    Has anyone performed any procmon tests to see why the exclusions are not working and which process is causing defender to scan the vhd files?  I'll ask the same thing in this thread as I found that after this thread which prompted me the check: https://social.msdn.microsoft.com/Forums/en-US/c6bbf232-6034-4dc8-9531-0fc9f5de78e2/windows-defender-scan-on-login-the-fslogix-vhd?forum=FSLogix

    I'll do my own testing soon, but I need to find another machine with the issue as I had to hard disable defender due to our policies forcing Realtime Monitoring back on every boot :)

    Monday, November 25, 2019 12:00 PM
  • So it is the real time defender that is causing the issue.

    I've added vhdx as an exception. I believe it is one of the built in Defender exclusions. As the mounting of the vhdx actually happens beneath the OS you cant pinpoint it within procmon.

    So a defender update seems to be ignoring the exclusions or hooking into the FSLogix driver.

    Monday, November 25, 2019 1:28 PM
  • Has anybody already a case with MS about this issue?

    Disable Realtime protection on enduser devices is not a nice workarround.

    Monday, November 25, 2019 1:35 PM
  • I'll confirm that we're seeing the same extremely long login times starting at the end of last week as well. We are also Windows Defender users, are on the latest FSLogix hotfix, have Defender exceptions for all known FSLogix executables and directories, and cannot disable realtime protection. We haven't rolled out FSLogix yet (it's in the last round of testing), and cannot do so until this is resolved.
    • Edited by galperinm Monday, November 25, 2019 3:41 PM
    Monday, November 25, 2019 3:40 PM
  • This release seems to be buggy. After the installation of 1909 HF_01 the user login takes 5-10 minutes and users receive black screens.

    After revert to version 2.9.7205.27375 all login issues are gone.

    We are currently working with the Windows Defender team to understand this issue, and drive to resolution.  Right now this appears to have been caused by a definitions update in defender.  I will update when I know more from them.  This does not appear to be caused by the 1909 HF1 release.
    Monday, November 25, 2019 7:11 PM
  • This issue where login takes 5-25 minutes is also present in Version 2.9.7117. The issue started from one day to the other. It also happens on different installations in different customer szenarios!

    We are currently working with the Windows Defender team to understand this issue, and drive to resolution.  Right now this appears to have been caused by a definitions update in defender.  I will update when I know more from them.
    Monday, November 25, 2019 7:12 PM
  • In our environment the issue with long login times started last week. Also from one day to the other.

    We run 2.9.7205.27375. Seems that the hotfix release is not fixing this issue.

    We also use the systemwide installation of OneDrive (19.174.0902). Anyone tried a newer version?

    We are currently working with the Windows Defender team to understand this issue, and drive to resolution.  Right now this appears to have been caused by a definitions update in defender.  I will update when I know more from them.
    Monday, November 25, 2019 7:12 PM
  • So it is the real time defender that is causing the issue.

    I've added vhdx as an exception. I believe it is one of the built in Defender exclusions. As the mounting of the vhdx actually happens beneath the OS you cant pinpoint it within procmon.

    So a defender update seems to be ignoring the exclusions or hooking into the FSLogix driver.

    We are currently working with the Windows Defender team to understand this issue, and drive to resolution.  Right now this appears to have been caused by a definitions update in defender.  I will update when I know more from them.
    Monday, November 25, 2019 7:12 PM
  • I'll confirm that we're seeing the same extremely long login times starting at the end of last week as well. We are also Windows Defender users, are on the latest FSLogix hotfix, have Defender exceptions for all known FSLogix executables and directories, and cannot disable realtime protection. We haven't rolled out FSLogix yet (it's in the last round of testing), and cannot do so until this is resolved.
    We are currently working with the Windows Defender team to understand this issue, and drive to resolution.  Right now this appears to have been caused by a definitions update in defender.  I will update when I know more from them.
    Monday, November 25, 2019 7:13 PM
  • We have had this version installed for a couple weeks now.  We have not been able to recreate the SharePoint bug where it creates 0KB files.  So far so good.  Thank you!!!

    We are, however, seeing the issue with Windows Defender.  


    Monday, November 25, 2019 7:52 PM
  • Hello, we have just received the following update:

    Signature version 1.305.2813.0 was published about 1 hour ago and should address this issue – and clients will update automatically in the next 24 hours. Impacted users can force an update (either from WU or from WD UX (or via manageability interfaces)). Please report if issues are still being seen with this version.

    Regards,

    Brent
    Monday, November 25, 2019 11:30 PM
    Owner
  • Our initial test shows the new virus definitions resolve the issue. Should there be additional information/issues we will report. 
    Tuesday, November 26, 2019 8:27 AM
  • Thank you for the update.

    Regards,

    Brent

    Tuesday, November 26, 2019 9:14 PM
    Owner
  • I think this hotfix still has issues, we still have Xenapp servers dying without any reason. I mean it could be something else but all we changed was the fslogix version. I'll revert back to see if it resolves things.

    Sunday, January 26, 2020 9:51 PM
  • Hi all, 

    We have been working on RDS 2019 with FSLogix for some months but are not able to get it stable. 
    We are running the latest versions of FSLogix and OneDrive. 

    In regards to the black screens at logon, we have found out this is caused by the AppReadiness service that seems to hang. When you check this service, you will find it to be running but you will not be able to stop it. If you kill AppReadiness the hard way, the login automatically completes but you will find the OS unresponsive (start-menu not working etc.)

    We have tried to work without AppReadines, just disabling the service but that prevents OneDrive from starting, so that was not really an option. Our workaround for now is to kill the AppReadiness service every night with a scheduled task. This seems to work OK but might cause some other issues. 

    Perhaps related but another observation was the extreme buildup of firewall rules when a user logs on. This becomes so many that the server really starts to slow down on performance. Even if you don't use Windows firewall, the rules are still created. We have applied a hotfix that deletes the firewall rules upon logoff, that seems to work OK.  

    Our long ongoing issues with FSLogix is OneDrive stability:

     - OneDrive Files on Demand feature not available (option is just not there)
     - OneDrive "Cannot connect to Windows" message (also files on demand related) 
     - OneDrive causes 0KB with 1980 date for synced Sharepoint sites (should be resolved in earlier release but still happens) 

    For all who have experienced the same and managed to resolve, please let us know! 


    Tuesday, February 4, 2020 4:04 PM
  • Hei Erik,

    We are running running the same environment as you, and OneDrive is working perfect with FSLogix.

    Have you enabled files on demand in the OneDrive GPO?

    How do you install OneDrive for the users. We use a script that install it at user logon if it is no present in the users profile.

    On a computer with latest OneDrive client, go to C:\Users\"username"\AppData\Local\Microsoft\OneDrive\"Version"\adm 

    There you will find OneDrive admx and adml. Copy these to your AD, an activate Files On Demand if this is not already done.

    Regards

    Fredrik

    Friday, February 14, 2020 9:03 AM
  • Microsoft have created a private hotfix for an app-v issue where application are not launching and told us it will be officially release at the end of January.
    We have sent multiple emails to have an update on that. Almost the end of march and no reply.
    • Edited by Francois Ra Thursday, March 19, 2020 8:58 PM
    Thursday, March 19, 2020 8:57 PM
  • I am having the same issue with support on FSLogix.

    Got issues where the profile containers just don't even attach at all, even if there is nothing locking the files. 

    Also an issue where FSLogix creates a corrupted Difference Disk container.

    Sent multiple log bundles and screen shots with descriptions of how they occured.

    Just tumble weed when trying to get anything from MS with regards to FSLogix.

    Thursday, April 2, 2020 9:06 AM
  • Hi Martijn,

    We are having the same issue with FSLogix latest hotfix running on Windows 2016 latest patches and Citrix CVAD 1912. We use FSLogix for Office container only and use Citrix UPM for profile management.

    We are getting issues where users local profile folders are not being cleared on logout consistently and the only way to resolve it is to restart the VDA which is not ideal in a live environment!

    We have tried this in both W2016 and W2019. We rolled back to W2016 as we were having issues with the native roaming user search database in in W2019 (only way around this was to add a scheduled task to fire on logout to restart the Windows search service so that the handle on the profile folder was released and it could be logged out), which is new to W2019, but we are still having issues in W2016, where no amount of restarting of Windows search service, Citrix Profile Management service any anything else seems to work except a reboot. We don't even have App-V or OneDrive enabled in this environment.

    Has anyone heard anything back from Microsoft with an ETA on when this will be resolved?

    Thursday, April 16, 2020 7:06 AM
  • Were you able to isolate which Apps were impacted on this release or if there was a common thread as to why. 
    Thursday, April 23, 2020 1:02 PM