Announcing general availability of FSLogix 2210 hotfix 3!

Our ticket with Microsoft has been open since February 15th and there is still no solution in sight. I now had a little time to illustrate the problem in more detail.

Hello FSLogix nation!

Microsoft is pleased to announce the availability of FSLogix 2210 hotfix 3 Preview (2.9.8716.30241).

This is a PREVIEW version, and we recommend first running in your non-production environments to fully test and understand the new updates and fix.

We've updated several new articles in our documentation and updated the release notes page.

Release Notes:

• Update: When new Teams is detected, the AppX package is registered for the user during sign-in.
• Update: During user sign-out, Teams user data/cache located in %LocalAppData%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache will be saved in the container.
• Fix: Resolved an issue where a virtual machine would reboot unexpectedly as a result of bug check (various stop codes) when a user's redirects were removed before sign-out

[UPDATE] January 9th, 2024:

First of all, I want to say "THANK YOU" to all of those who've been testing and validating this hotfix preview release. Based on the testing and feedback I'd like to report on the current status:

All:

• Potential anti-virus conflicts. Teams 2.1 paths have changed, and some anti-virus products have prevented the Teams executables from launching correctly.  Confirm with your vendor if any changes are needed to be compatible with Teams 2.1.

Windows 10 and 11 (Enterprise and Multi-session):

• Operating systems have the correct API(s) for proper discovery and registration for UWP / AppX packages.
• Profile only, Profile and ODFC, and ODFC only configurations working as intended.
• Preservation of Teams user data in %LocalAppData%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache working as intended.

Windows Server 2022:

• [Unable to reproduce] Teams 2.1 fails to launch / start with a message, "msteams_autostarter.exe 'The parameter is incorrect'" (Looking for customers to help investigate and reproduce).

Windows Server 2019:

• [Confirmed] Missing API for UWP / AppX packages preventing discovery and registration (under investigation).
• [Unable to reproduce] Failure to instantiate storage folder C:\Users\%username%\AppData\Local\Packages\MSTeams_8wekyb3d8bbwe\LocalCache for package MSTeams_8wekyb3d8bbwe with Error Code: -2147024809 (Looking for customers to help investigate and reproduce).

Once we can confirm we've addressed the issue above, we will plan for an updated release for hotfix 3 (updated version).

Cheers,

Jason Parker, Sr. Program Manager for FSLogix

Windows Cloud Experiences at Microsoft

StevenM2330We added new Teams startup to a logon script (scheduled task at any user logon), rightly or wrongly I'm sure opinion is divided! Anyway, in case it's of some help, here's the new Teams section of our logon script:

Write-Host "!!!!  Begining MSTeams section  !!!!"
# Space to separate logs
Write-Host " " 
$app = (Get-AppxPackage | Where-Object -Property Name -EQ -Value MSTeams)
Write-Host "MSTEAMS: App: $app"
$pkgName = $app.PackageFamilyName
write-Host "MSTEAMS: Package Family Name: $pkgName"
$startupTask = ($app | Get-AppxPackageManifest).Package.Applications.Application.Extensions.Extension | Where-Object -Property Category -Eq -Value windows.startupTask
write-Host "MSTEAMS: Startup Task: $startupTask"
$taskId = $startupTask.StartupTask.TaskId
Write-Host "MSTEAMS: Task ID: $taskId"
$state = (Get-ItemProperty -Path "HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\$pkgName\$taskId" -Name State -ErrorAction SilentlyContinue).State
Write-Host "MSTEAMS: State: $state"
$userStartup = (Get-ItemProperty -Path "HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\$pkgName\$taskId" -Name UserEnabledStartupOnce -ErrorAction SilentlyContinue).UserEnabledStartupOnce
Write-Host "MSTEAMS: User Enabled Startup Once: $userStartup"
$regKey = "HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\$pkgName\$taskId"
Write-Host "MSTEAMS: Reg Key: $regKey"
if ($state -in 0,1,3) {
    Set-ItemProperty -Path $regKey -Name UserEnabledStartupOnce -Value 1 -Force
    Set-ItemProperty -Path $regKey -Name State -Value 2 -Force
	Write-Host "MSTEAMS: MSTeams State was 0 or 1 or 3, writing values"
} 
elseif ($userStartup -in 0) {
    Set-ItemProperty -Path $regKey -Name UserEnabledStartupOnce -Value 1 -Force
	Write-Host "MSTEAMS: MSTeams State was 0 or 1 or 3, but userStartup was 0. Writing value to 1."
} 
elseif ( ($state -in 2) -and ($userStartup -in 1) ) {
	Write-Host "MSTEAMS: MSTeams State was 2 and userStartup was 1 already, no action required."
} 
else {
			Write-Host "MSTEAMS: AppxPackage not registerd yet, adding values based on expected paths"
			$expRegPath = "HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask"
			$expRegKey = try {
					Get-Item -Path $expRegPath -ErrorAction Stop
					Write-Host "MSTEAMS: MSTeams reg key path exists"
						}
						catch {
						New-Item -Path $expRegPath -Force
						Write-Host "MSTEAMS: MSTeams reg key path not found, adding key"
						}
			Write-Host "MSTEAMS: Setting force of MSTeams State and User Startup values"
			Set-ItemProperty -Path $expRegKey.PSPath -Name State -Type DWord -Value 2 -Force -ErrorAction SilentlyContinue
			Set-ItemProperty -Path $expRegKey.PSPath -Name UserEnabledStartupOnce -Type DWord -Value 1 -Force -ErrorAction SilentlyContinue
			Write-Host "MSTEAMS: Finished force of MSTeams State and User Startup values"
}

$addinPath = "HKCU:\Software\Microsoft\Office\Outlook\Addins\TeamsAddin.FastConnect"
$addinKey = try {
    Get-Item -Path $addinPath -ErrorAction Stop
	Write-Host "MSTEAMS: MSTeams Addin path exists"
}
catch {
    New-Item -Path $addinPath -Force
	Write-Host "MSTEAMS: MSTeams Addin path not found, adding key"
}
Write-Host "MSTEAMS: Setting MSTeams Addin values"
Set-ItemProperty -Path $addinKey.PSPath -Name Description -Type String -Value "Microsoft Teams Meeting Add-in for Microsoft Office" -Force -ErrorAction SilentlyContinue
Set-ItemProperty -Path $addinKey.PSPath -Name FriendlyName -Type String -Value "Microsoft Teams Meeting Add-in for Microsoft Office" -Force -ErrorAction SilentlyContinue
Set-ItemProperty -Path $addinKey.PSPath -Name LoadBehavior -Type DWord -Value 3 -Force -ErrorAction SilentlyContinue
Write-Host "MSTEAMS: MSTeams Addin values set"
# Space to separate logs
Write-Host " " 
Write-Host "!!!!  Finished MSTeams Section  !!!!"

I think it's about time Microsoft made an official statement about this problem. The forums on various platforms (Microsoft, Reddit, etc.) are full of problems with Teams 2.1 and multi-user platforms. Many have opened a ticket with Microsoft but have not yet received a solution (we have been waiting on our case since February 15th).

I understand Jason when he says that they can't reproduce the problems in the lab, but it seems that the real world doesn't work like the lab (otherwise there wouldn't be so many problems with it).

Maybe Microsoft needs to find a solution directly with the antivirus manufacturers, because it looks like Microsoft built something that simply doesn't work out of the box.

You can patch directly to Hotfix 3 without stepping.  Each release is a full install, so you can either start with this, or upgrade to this and you are fine.

You can install the new admx and adml.  Any entries that are deprecated in the admx and adml show up as additional registry entries.  So you may want to migrate those features before hand to registry entries, or edit the policy manually after you are upgraded to remove them from the xml  file.

The reason I was asking about the single user version was because the hotfix says it is for Multi-Session and 2022 only.  Will there be another version that supports 2019 and single-user session in the release notes?  Or will the release notes be modified to include the other operating systems.

Thanks martinss for the script! Already had something similar in mind as a workaround for my first issue, but this saves me the trouble. Very much appreciated! Will test this out soon.

Now i’m still looking for a resolution/workaround for my second issue. If someone knows how to prevent the msteams_autostarter.exe error after removing a users FSLogix ODFC container, that would be great! That is the last thing preventing us from rolling out the new teams client

Karl-WE New Teams with Server 2019 and FsLogix? This isn't supported at the moment: New Teams on Windows Server 2019 currently isn't compatible with FSLogix and fails to launch (https://learn.microsoft.com/en-us/microsoftteams/new-teams-vdi-requirements-deploy).

I wanted to share what I have learned testing with Server 2019.

For background this is Citrix XenApp environment build with App Layering.

When testing the preview version of FSLogix 2.9.8716.30241 without my Office 365 layer everything worked great, old and new profiles opened New Teams without issue. Once I added the O365 layer I would consistently get the 'Failure to instantiate' event for all profiles (new and old).

I have gotten different results with the new GA FSLogix version 2.9.8784.63912 on Server 2019. New profiles work without issue. Old profiles get the 'Failure to instantiate' event. Once an old profile gets that error, all profiles also fail to open Teams.

This is a non-persistent App Layered environment and a restart appears to clear something that allows new profiles to work again as well as other previously existing profiles that never experienced the error. Any profile that previously experienced the 'Failure to instantiate' event will not work, even after the restart.

I have a little update I would like to share with the community regarding the issues I was running into. Might help someone else... ( Jason_Parker might be usefull to improve the product, so we do not have to do these tricks to make it work)

Issue 1: Teams Autostart not roaming / saved in FSLogix container

By roaming the following 2 registry keys with our Ivanti Environment Manager profile solution I was able to make this work:

- HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask\State (DWORD)

- HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask\UserEnabledStartupOnce (DWORD)

Auto start setting in file %localappdata%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams\app_settings.json is not the one that manages the autostart of teams, this seems only for display purposes in the interface.

Issue 2: Error C:\Program Files\WindowsApps\MSTeams_24004.1307.2669.7070_x64__8wekyb…\msteams_autostarter.exe. Incorrect function

I managed to work around this issue by creating folder "%localappdata%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache" at logon if it isn't there already.

When you remove the FSLogix container for the user, somehow the default configuration isn't recreated. This causes the error. By creating the mentioned folder the default configuration is recreated and the application starts working again at logon

Issue 3: User has to disable/enable "Auto-start Teams" before auto-start works correctly. In the interface option is default enabled, but not working.

At logon check if HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask\State = 2, if so set HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask\UserEnabledStartupOnce = 1

After this teams will auto-start after a user has launched new teams once, and they are still able to modify the setting

Now I still have one issue remaining, perhaps someone else knows a solution for this. We would like to set some default configuration for new users (for instance enabling the "Open application in background" option by default). We tried this by placing a modified versions of "%localappdata%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams\app_settings.json" before the user starts the new teams for the first time. But unfortunately the file is overwritten with a default configuration (entire folder is removed at first launch, we saw this in procmon traces we made).

How can we modify the user default settings?

Thanks StevenM2330 for the detailed information.

Issue 1: Teams Autostart not roaming / saved in FSLogix container

By roaming the following 2 registry keys with our Ivanti Environment Manager profile solution I was able to make this work:

- HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask\State (DWORD)

- HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask\UserEnabledStartupOnce (DWORD)

 

Auto start setting in file %localappdata%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams\app_settings.json is not the one that manages the autostart of teams, this seems only for display purposes in the interface.

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

Issue 2: Error C:\Program Files\WindowsApps\MSTeams_24004.1307.2669.7070_x64__8wekyb…\msteams_autostarter.exe. Incorrect function

I managed to work around this issue by creating folder "%localappdata%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache" at logon if it isn't there already.

When you remove the FSLogix container for the user, somehow the default configuration isn't recreated. This causes the error. By creating the mentioned folder the default configuration is recreated and the application starts working again at logon

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.

Issue 3: User has to disable/enable "Auto-start Teams" before auto-start works correctly. In the interface option is default enabled, but not working.

At logon check if HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask\State = 2, if so set HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask\UserEnabledStartupOnce = 1

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.

Thanks again for the details and feedback!