Teams on RDS - Issue with Meeting Plugin

Teams Meeting Add in Issue on RDS and VDI

Your MSI command is correct. The issue is being caused by the folder copy workaround rather than the installation command itself.

The path mismatch is the key indicator.

Administrator accounts reference the correct current path because their per user Teams Meeting Add in installation succeeds during logon.

Standard users reference an older path because their per user installation is likely failing silently. A common cause is Windows Installer error 1625:

Installation forbidden by system policy

This is commonly triggered by AppLocker publisher rules or MSI installation restrictions configured through Group Policy.

As a result, standard users remain registered against whichever Teams Meeting Add in version was previously available on the machine.

1. Confirm the Installation Failure

Log in using a standard user account and open:

Event Viewer Windows Logs Application

Filter the Source by:

MsiInstaller

Look for Event ID 1625 around the user's logon time.

If this event appears, it confirms that the per user MSI installation is being blocked by policy.

1. Avoid the Folder Copy Workaround

Copying the current Teams Meeting Add in folder into the older path may temporarily resolve the problem, but it is not a sustainable solution.

When Teams updates again, a new TMA version and folder will be deployed. The user's registration will once again reference an outdated location.

The underlying registration and installation model needs to be corrected instead.

1. Configure Machine Wide Registration

Installing the MSI machine wide places the files on the server, but the Outlook add in should also be registered under HKLM so that all users inherit the configuration.

Use the following registry location:

HKLM\Software\Microsoft\Office\Outlook\Addins\TeamsAddin.FastConnect

Configure these values:

LoadBehavior Type: DWORD Value: 3 Description Type: String Value: Microsoft Teams Meeting Add-in for Microsoft Office FriendlyName Type: String Value: Microsoft Teams Meeting Add-in for Microsoft Office

An important consideration is that HKCU takes precedence over HKLM.

If a user has the same TeamsAddin.FastConnect key under HKCU and LoadBehavior is configured with a value other than 3, the machine wide registration can effectively be overridden.

It is therefore worth checking and cleaning up conflicting HKCU entries as part of the rollout.

1. Use the Teams Bootstrapper

Instead of manually hardcoding the Teams Meeting Add in version, Microsoft provides a bootstrapper option that can handle version matching, folder paths and registration.

Use:

teamsbootstrapper.exe -p --installTMA

This can be run after Teams is updated on the image.

If the following configuration is enabled:

disableAutoUpdate = 1

running only:

teamsbootstrapper.exe -p

will not install the Teams Meeting Add in machine wide.

In that scenario, the following parameter must be included:

--installTMA

1. If You Continue Using the MSI

If you prefer to continue using the MSI installation method, avoid manually specifying the version wherever possible.

Detect the installed Teams Meeting Add in version dynamically and use that version during deployment.

Also make sure TARGETDIR remains identical for every installation.

For example, if your current deployment uses:

TeamsMeetingAddin

continue using the same location consistently.

Microsoft documentation may reference:

TeamsMeetingAdd-in

The exact folder name is less important than maintaining the same TARGETDIR between installations. Changing the path can prevent the MSI from correctly identifying and removing previous versions.

1. Configure the VDI Environment Setting

On the image, configure:

HKLM\Software\Microsoft\Teams

Create or configure:

IsWVDEnvironment Type: DWORD Value: 1

This tells Teams that it is operating in a virtualized environment and helps ensure that the machine wide deployment model is used instead of repeatedly attempting per user installation during logon.

1. Additional Image Checks

While reviewing the image, also verify the following:

Teams and the Teams Meeting Add in are correctly handled by your antivirus and DLP configuration.

Microsoft Edge WebView2 Runtime is installed and current.

Windows Server 2022 is running build 20348.2402 or later.

Security software should also be reviewed carefully because application control or endpoint security products can prevent Teams Meeting Add in registration without presenting an obvious error to the user.

1. Validate the Result

After completing the configuration, log in using a standard user account.

In Outlook, navigate to:

File Options Add ins

The Teams Meeting Add in should appear under:

Active Application Add ins

Confirm that it points to the current Teams Meeting Add in version path.

At that point, no manual folder copying should be required.

Additional Technical Reference

A full technical writeup covering version detection, AppLocker considerations and Teams bootstrapper error codes is available here:

https://mstack360.com/teams-meeting-add-in-not-showing-rds/