Forum Discussion

Ken_Z's avatar
Ken_Z
Brass Contributor
May 15, 2024
Solved

2210 HF4 still broken on Server 2019 and new Teams

Hi Everyone,

 

so, I assume everyone's been testing the new 2210 HF4 this morning/last night?

 

I've got two Citrix Session Hosts, Server 2022 and Server 2019

Both of them have the latest FSLogix installed, and they share the same GPO for the FSLogix configuration. 

They've also got a common redirections.xml file for both Servers. Logging into a Session host creates both a normal profile folder and a local_<user> folder for redirected folders/files

For testing, I've been deleting the vhdx files between tests on each server, so there's no potential issues using a profile container between the two different OSes.

Also, I've only got a single profile container configured - I'm not using an Office container

I've also got the latest new Teams installed on both servers. Server 2022 was installed via the bootstrapper and Server 2019 was installed via DISM as per the recommended method.

 

Server 2022 - when i log in to this OS using a test account configured for FSLogix, and start new Teams, everything is fine. When i log off, both the user profile and local_<user> folders get deleted.

 

Server 2019 - Doing exactly the same operation on this server, after starting new Teams, then logging off, the local_<user> folder fails to get deleted. The error message in the FSLogix operational logs are "Error removing directory: C:\users\local_<xxxx>\AppData\Local\Microsoft\IdentityCache\1\UD\.... The process cannot access the file because it is being used by another process)"

 

Note that the location under AppData\Local\... can change between different tests as there are a lot of different files locked and this is the first file FSLogix came across during the logoff process.

 

Running sysinternals Handle64.exe shows that the files are open by "System" (pid = 4)

Also, I can't delete the folders manually as administrator after the user has logged off either, unless i reboot the server.

 

This issue only occurs after I've run new Teams for the first time. If i start clean without a profile container, log in, start Word, Excel, Outlook, etc, but don't start new Teams, the issue doesn't occur. Once I've started Teams, even if i shut it down, the local_<user> folder can't be removed/deleted.

 

Anyone else experiencing this?

 

  • OK, if anyone is interested, I got to the bottom of this issue. I had to remove the following entries from my redirections.xml file as New Teams was causing the system to keep the files in these folders locked after logoff. (This only occurs on Server 2019, not Server 2022)

    <Exclude Copy="0">AppData\LocalLow</Exclude>
    <Exclude Copy="0">AppData\Local\D3DSCache</Exclude>
    <Exclude Copy="0">AppData\Local\Microsoft\IdentityCache</Exclude>
    <Exclude Copy="0">AppData\Local\Microsoft\OneAuth</Exclude>
    <Exclude Copy="0">AppData\Local\Microsoft\TokenBroker</Exclude>
    <Exclude Copy="0">AppData\Local\Microsoft\Windows\Caches</Exclude>
    <Exclude Copy="0">AppData\Local\Microsoft\Windows\Explorer</Exclude>
    <Exclude Copy="0">AppData\Local\Microsoft\Windows\IECompatCache</Exclude>
    <Exclude Copy="0">AppData\Local\Microsoft\Windows\iecompatuaCache</Exclude>

    Once these were removed, the local_<user> folder was successfully being deleted.
    NOTE this is my standard xml file that i've been using for years and hasworked without incident, and still works on Server 2022. Definitely an issue with New Teams on Server 2019.

    Note the LocalLow was removed but it was only a couple of files in the Microsoft subfolder that was causing the issue.
  • jsplatt's avatar
    jsplatt
    Copper Contributor

    We have a similar issue with Server 2019 and FSLogix ODFC containers causing files/folders to be locked by the "System" process preventing a users profile from being fully removed on logout.

    I have also seen 5 or 6 others with this issue across various forums and Reddit posts.


    For us, the only way to get the profile to be removed on logout is to ensure that the following folder/symbolic link that is created by FSLogix is removed before Teams is loaded.

    AppData\Local\Microsoft\Teams

    Apparently Microsoft have been made aware of this issue and above workaround but if/when it might be addressed.....

    • prodriguez's avatar
      prodriguez
      Copper Contributor

      Hi jsplatt,

      Same issue for me... and same workaround read on the forums you mention.

      How do you clear this folder AppData\Local\Microsoft\Teams ?

      As it seems to be locked by the system, even if Teams is not launched. It also asks for admin rights, so itmeans a user script which clear the folder prior to launch Teams could not work.

      I tried on my side, I did not succeed to clear...

       

      Hope you can help,

       

      Best regards,

      • jsplatt's avatar
        jsplatt
        Copper Contributor

        I believe that when a user logs in FSLogix creates that folder and then when Teams loads it becomes locked.

        Our workaround is to delete that folder at logon before Teams can load and lock the folder.

        We are using WEM to delete the folder at logon but you might be able to achieve the same with a Windows logon script if that is not available to you, either way you will need to run/delete the folder before Teams loads as that's what appears to cause it to become locked.

        Let me know if you need any further information.

      • Ken_Z's avatar
        Ken_Z
        Brass Contributor
        Thanks Daniel

        I noticed an error in the article specifically the TempState Location. They missed the "Local" part out after AppData. There is not "Packages" folder directly under AppData

        Regards

        Ken Z
  • Hans_4086's avatar
    Hans_4086
    Copper Contributor

    I also struggled over this but then i checked my FSLogix Installation with frxtray.exe

    The Version that should be running is:

    FSLogix Service Version 2.9.8884.27471 Status: RUNNING
    FSLogix Kernel Driver Version 2.9.8884.27471 Status: RUNNING
    FSLogix Kernel Virtualization Driver Version 2.9.8884.27471 Status: RUNNING

     

    but why is it running the old Version 2.9.8784.63912 after the Update?

     

    So i uninstall FSLogix and make sure that is no FSLogix in C:\Program Files and in ProgramData.

    Reboot the Server and install the new Version of FSLogix and reboot again.

    Now the new Version 2.9.8884.27471 is running checked with frxtray.exe

     

    Hope this will help.

     

    • Ken_Z's avatar
      Ken_Z
      Brass Contributor
      Hi Hans
      I'd completely uninstalled the old version before installing the new one, but I've just re-checked anyway. Under Driver Interface i see

      Profile Version: 6
      Installed system RAM: 8191 MB (load: 42 %)
      FSLogix Service Version 2.9.8884.27471 Status: RUNNING
      FSLogix Kernel Driver Version 2.9.8884.27471 Status: RUNNING
      FSLogix Kernel Virtualization Driver Version 2.9.8884.27471 Status: RUNNING

      so it's all at the correct version.

      Regards

      Ken Z
      • Ken_Z's avatar
        Ken_Z
        Brass Contributor
        I've logged this with Microsoft today. The engineer who I spoke to says he's seen already seen this! and it's only ben 24 hours since HF4 came out.
  • Ken_Z's avatar
    Ken_Z
    Brass Contributor

    I should mention that i was also getting this exact behaviour with HF3 as well, but was hoping that HF4 would fix it. A customer that has Server 2019 RDS is also experiencing the exact same issue with HF3,

    I also tried completely removing FSLogix, deleting all the regkeys under HKLM\SOFTWARE\FSLogix and HKLM\SOFTWARE\Policies\FSLogix, then installed HF4 as a clean install, and the same issue occurred.

     

    The issue does not occur with Classic Teams

Resources