MicrosoftIf you are using FSLogix profile or profile with ODFC containers, then this doesn't make much sense. HKEY_CURRENT_USER is based on the NTUSER.dat file located inside the user's profile (in this case FSLogix container). FSLogix loads this hive from NTUSER.dat which is integral for the entire profile and not just Teams autostart. If you are not using the FSLogix profile container at all, then this makes more sense and seems like a gap in the profile solution you're using.
We are only using FSLogix ODFC container (so no profile container). In our profile solution (Ivanti Environment Manager), we have do define which registry keys and files have to be saved in order to make them persistent/roaming. It might be usefull for others to mention saving these 2 registry keys in the documentation in case someone would like to persist/roam auto-start of teams.
The Microsoft Teams and FSLogix engineering teams have not been able to reproduce this error in any of our testing environments. We have worked directly with 3 customers who've had this issue and all 3 customers resolved this issue with their various antivirus products (SentinelOne, Palo Alto, and Trend Micro). We have also worked directly with a customer who has this issue and the AV exclusions are not working. This customer had all the folders and paths populated correctly and it didn't appear to be anything related this path. While the path is important, in the cases we've seen, this path and structure has existed.
Question: What OS are you seeing this issue occur in? Can you share more about your environment or configuration? Please DM me or send me an e-mail as we are diligently working to solve these issues.
I have tested without AV Solution (we use VMWare Carbon Black), but the issue is still there. I will send you an e-mail with the steps to reproduce.
Similarly to Issue 1 above, FSLogix will roaming the user registry hive (NTUSER.dat) and relys on the data to be populated correctly for the user. If the registry keys are not getting set correctly, then we can take that to the Teams engineering team to review.
The registry key is not set correctly by Teams at first launch, until the user disables and re-enables the auto-start option in the interface. Only then auto-start begins to work. HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask\UserEnabledStartupOnce should be set to value 1, otherwise the startup task will not launch
