Forum Discussion
New Teams / Meeting addin missing on Windows Server 2019 RDSH / Autostart Issue
Spragaz Dirkberlin thoger5 kingrafe
We currently have no solution, only some disappointing "workarounds".
First of all, we still have Teams Classic installed for the Meeting Addin functionality. This is a bit of a mess because of the load of data stored in the profile disks, but still better than missing the plugin functionality.
Second, altough both Teams Classic and "new" Teams are startable via the Start Menu none of them would start when the user logs in. If we set Teams to run on startup, no matter if in Teams itself or via the Startup Apps, after re-login, these settings are gone. Solution? We put a shortcut into the Windows public startup folder.
Some users also report issues with the "Update" functionality, where Teams seems to be the current version, but still prompts for updates.
Kinda sad experience to have to rely on such immature products, even months after you were forced to use them.
calaneo @Spragaz @thoger5 @kingrafe
Hello,
yesterday I tried the workaround to install the plugin manually as an admin on my test environment server 2019.
That worked for me in the test environment. The plugin was installed for the testuser. But I guess it will not update automatically in the future, as the user has no right to install.
My problem and this workaround is described here:
https://learn.microsoft.com/en-us/microsoftteams/new-teams-vdi-requirements-deploy#teams-meeting-add-in
In the log file for the tma addin, I found the error "Installation success or error status: 1625." which means there seems to be a policy restricting this. However, there is no policy in place.
I will continue testing it..
EDIT:
I must have set a registry entry incorrectly yesterday. Now that I have corrected this, the Meeting Add-In is installed automatically.
You can find it in the link above.
I have set the registry values for DisableMSI and DisableUserInstalls.
Teams started automatically for me, I have no problem with that.
I now have new Teams and the add-in is also provided automatically. The user profiles are saved via FSLogix.
Did you deploy Teams via DISM as indicated in the link?
I will now try for some other users...
Best regards
Dirk
- Hi Dirk,
thanks for the note! We're currently examining which user impact the setting "DisableUserInstalls" would have, as we don't allow it currently.
We took a deep dive into system flows and found out, the startup problems with the new Teams Client were triggered by the User Profile Disks. The required Registry entries were wiped completely during sign out and the new Teams seems to be installed again (along with the registry entries) from the windowsapps folder during sign-in.
We cross-tested this on a remoteapp server that is running in our infrastructure without UPDs but the same policies, and the new Teams is running there as it should (but without the Meeting Addin, due to DisableUserInstalls).
We came to the point that we should upgrade the servers to Windows Server 2022 first, possibly followed by setting up FSLogix, because we think that Microsoft will do nothing about this.- Hi calaneo,
so, you don't use FSLogix right now?
Please note:
Folder Redirection or Roaming User Profiles aren't supported with the new Teams client in VDI environments since they can't roam folders in AppData\Local\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams.
Customers can continue to use Folder Redirection or Roaming User Profiles with a complementary product, such as FSLogix, Citrix Profile Manager, and VMware DEM, that can roam the Appdata\Local folders above.
Maybe that's your problem?- Yes, this formulation is pretty much spot on. Currently we are using standard UPDs. That's why we want to switch to FSLogix soon. Thank you for the hint!
Hi, i got the exact same error message "code 1625".
We are using non-persistent desktop, thats why a per user installation is in fact no option for us.
After the first update we will see, if we would have to update the addin as well (which isn't really a big deal).
