Forum Widgets
Latest Discussions
FSLogix 2210 (2.9.8361.52326) bugs: black screen and log off issues
Hi all, there seem to be a couple of bugs in FSLogix 2210 (2.9.8361.52326): some users experience a black screen when logging on (loading their profile may take up to 10-15 minutes), session logoffs don’t work (child processes have to be killed) and user profile roaming between different session hosts is problematic. Workaround: I had to fall back to the FSLogix 2201 hotfix 2 (2.9.8228.50276). There were no more issues since then. For now I keep all my customers on this build.
Fslogix (2.9.8308.44092)
i use citrix xenapp xendesktop 2203 multi user session on windows server 2019 with fslogix everything worked fine but yesterday since i updated fslogix to FSLogix version 2210 (2.9.8308.44092) for vhdx compaction outlook asks the user for the password at log off if he forgets it and then at the next login he asks for it. depends on what?
Only up to 5 users can login, following won't attach profile disk
We have a RDS cluster with 2 hosts, since a few days one host has a problem that it can handle 5 users only. Every next user has problems logging in, it won't attach the profile disk. Details about environment: - Windows server 2022 - FSLogix 2.9.8228.50276 -> Issue the same after updating to 2.9.8612.60056 - Profile disks on separate file server SMB share - Appx and recycle bin roaming is disabled The first 5 users can login normally, but the 6th user starts to have problems. It is stuck for 5 minutes on "Please wait for the FSLogix Apps Services". When I check the logs I can see a timeout (5 minutes) when trying to attach the profiledisk: [10:13:50.811][tid:00000c0c.00005d94][INFO] Configuration setting not found: SOFTWARE\FSLogix\Profiles\LockedRetryInterval. Using default: 5 [10:18:50.868][tid:00000c0c.00005d94][ERROR:00000079] Failed to attach VHD. (The semaphore timeout period has expired.) [10:18:50.868][tid:00000c0c.00005d94][INFO] VHD(x) attach request returning after 300016 milliseconds [10:18:50.873][tid:00000c0c.00005d94][INFO] Status set to 12: Cannot attach to virtual disk [10:18:50.874][tid:00000c0c.00005d94][INFO] ErrorCode set to 121 - Message: The semaphore timeout period has expired. [10:18:50.874][tid:00000c0c.00005d94][ERROR:00000079] Failed to attach virtual disk: \\fs01\Profiles$\user_xxxx_S-1-5-21-1315411913-3787531913-3827759124-6435\Profile_user_xxxx.VHDX (The semaphore timeout period has expired.) [10:18:50.875][tid:00000c0c.00005d94][INFO] Session configuration wrote (DWORD): SOFTWARE\FSLogix\Profiles\Sessions\S-1-5-21-1315411913-3787531913-3827759124-6435\RefCount = '0' In the Windows eventviewer (Application) I can see the following warnings: The winlogon notification subscriber <frxsvc> is taking long time to handle the notification event (Logon). The winlogon notification subscriber <frxsvc> took 300 second(s) to handle the notification event (StartShell). And sometimes the following: The Desktop Window Manager process has exited. (Process exit code: 0x800401f0, Restart count: 1, Primary display device ID: ) What I've tried so far: - Update FSLogix - Disabled AV software (Sophos) The RDS collection contains two servers, the other server does not have this problem. We couldn't find any obvious difference between de servers.
FSLogix with O365 Container on RDS 2019 Server, some users Intermittently get "The information store
We have a RDP Server farm with 3 servers currently in the farm. I inherited this FSLogix setup from someone else, and I also inherited this issue. We have about 20 users on each RDS Server. Generally in the morning when some (about 2) users sign in for the day, when they open outlook, they get an error message: "Cannot start Microsoft Outlook. cannot open the outlook window. The set of folders cannot be opened. The information store could not be opened." Launching outlook again doesn't help, it throws the same issue. So far the only workaround we have which seems to work reliably, is we open another office application, like word, sign out of the office account, under file -> account, then sign back in. Then we can use outlook fine. Tomorrow the same users might not be affected, there might be 2-3 others that is affected, sometimes the same user is affected 2 days in a row. From what I can tell the container for Office is successfully attaching, and I think the clue that signing out of word and back in fixes it should tell me something about what is causing it, but so far no luck. Things I have tried so far. Setting outlook to cached mode. Hybrid joining the servers disabling adal (multifactor doesn't work) Clearing the outlook profile and re-creating it. Other bits of information. Users are federated with ADFS, and ADFS uses a Duo Multi factor plugin for MFA. FSLogix is on version 2.9.8228.50276 any idea where to look next would be appreciated. Edited to mention FSLogix Version
Azure VDI - Outlook Stuck on 'Loading Profile'
Issue occurs every morning and we have been chasing this up with the Microsoft support team as well. We've tried a lot of things but switching to and from VDI's seems to eventually get people logged in. We've rebuilt mail profiles, safe mode, resetnavpane, disabled add-ins, updating Office, restarted VDIs, deleted duplicate user profiles on the VDI, deleted OSTs and temp files within AppData, cleared credential manager. One thing which seemed to help was running Microsoft SaRA. It said we had modern authentication setup on our tenant and the VDIs were using legacy. It performed the fix and sorted the issue right away. It looked to calm the problem for some time but more people started getting this again. Something to note is this usually happens in the mornings or just when someone starts work. I know a lot of people experience the same issue but not come across a reliable fix so far.
Error copying profile (0x00000001): Incorrect function.
The latest version of https://learn.microsoft.com/en-us/fslogix/overview-release-notes#fslogix-2210-hotfix-4-29888427471 is experiencing problems with the command: frx copy-profile C:\Program Files\FSLogix\Apps>frx copy-profile -filename d:\temp\Profile_test.vhdx -username test -size-mbs=30720 -dynamic=1 label=profile-test-verbose User test" SID is "S-1-5-21-2971068368-244597684-1576390238-2601" Volume Label: profile-test Session count: 6 Found user: Found user: Found user: test Found user: Found user: Found user: VHD not found. Creating... Create success. Attaching... Attach success. Getting physical path... Get physical path success. Opening device... Open device success. Initializing disk... Initialize disk success. Getting volume name... . Formatting volume: \\?\Volume{5bc41fa6-5d2b-4389-99de-f4306343069c}\ Format success GetSecurityDescriptor success GetDACL success Set security success Copying profile for user S-1-5-21-2971068368-244597684-1576390238-2601 to volume \\?\Volume{5bc41fa6-5d2b-4389-99de-f4306343069c}\ Looking for Profile Path in registry CopyProfileToVolume SID: S-1-5-21-2971068368-244597684-1576390238-2601 Volume: \\?\Volume{5bc41fa6-5d2b-4389-99de-f4306343069c}\ profileImagePath: C:\Users\test Exporting registry information Export Profile registry data error: 0x00000001 Error copying profile (0x00000001): Incorrect function. After downgrading to version 2.9.8612.60056, I was able to migrate the local profile. However, the command needed to be run twice because the first attempt resulted in an error: Export Profile registry data error: 0x00000002 Error copying profile (0x00000002): The system cannot find the file specified.
FSlogix Profile associating to wrong Azure Machine registration
Hello, We have Citrix non persistent VDI setup with FSLogix profile management. We use MS Office only for Word and Excel - there is no Outlook or Teams setup. We have hybrid deployment with we do not sync Non persistent VDI OU to Azure. Machines register as users' devices when they log in to MS Office only. During DR exercise we moved users from Production datacenter and DR datacenter Citrix Storefront. Machine name of these non-persistent windows 2019 VDIs on both ends have different names. The FSLogix profile from Prod was Robocopy to DR file share. There are two issues 1- That when user Office token tries renewing it shows in Azure User logs that it was attempted using the old VDI machines name. The activation then fails with 62ubh error. To resolve we can remove the old machine's associated to the user's under the Azure profile and then remove Microsoft.AAD.BrokerPlugin_vnggnktrrj file in C:\%Userprofile%\AppData\Local\Packages. Have the user reboot and then reactivate office. 2- At that point after it takes two tries, it times out with CA0000 error, that device could not be registered- but user gets logged in to MS Office. The VDI from DR never registers in Azure under the user's name under Devices. No issue DSREGCMD /Status and machine has SCP access. We are not resetting the Profiles because it takes time copying their setup preferences.
