Teams Meeting Add-in Not Showing for Non-Admin Users on RDS

If Outlook on your Remote Desktop Server (RDS) shows the Teams Meeting Add-in for admins but not for standard users, you are hitting a known installation policy conflict. Here is what is causing it and how to fix it permanently.

What is actually happening#

The durable fix: two options#

Option A: Bootstrapper install (cleanest, recommended)#

Run the Teams bootstrapper with the TMA flag on your RDS host or base image as part of your Teams deployment. Re-run it after each Teams update.

teamsbootstrapper.exe -p --installTMA

That is the entire command. Microsoft's own tooling handles version matching, folder path, and registration.

If Teams was already provisioned and you only need to install or refresh TMA, drop the -p:

teamsbootstrapper.exe --installTMA

Option B: MSI method, made resilient#

Stop pinning a fixed version. Use the PowerShell script below to detect the TMA version bundled with the Teams build currently on the machine, install it to a consistent TARGETDIR, and register it machine-wide. Re-run on every Teams update.

# Get the Teams package version currently installed
$NewTeamsVersion = (Get-AppxPackage -Name MSTeams).Version
$TMAPath = "{0}\WINDOWSAPPS\MSTEAMS_{1}_X64__8WEKYB3D8BBWE\MICROSOFTTEAMSMEETINGADDININSTALLER.MSI" -f $env:programfiles, $NewTeamsVersion
$TMAVersion = (Get-AppLockerFileInformation -Path $TMAPath | Select-Object -ExpandProperty Publisher).BinaryVersion
$TargetDir = "{0}\Microsoft\TeamsMeetingAdd-in\{1}\" -f ${env:ProgramFiles(x86)}, $TMAVersion
$params = '/i "{0}" TARGETDIR="{1}" /qn ALLUSERS=1' -f $TMAPath, $TargetDir
Start-Process msiexec.exe -ArgumentList $params

TARGETDIR must stay consistent across updates so the installer can detect and clean up previous versions. If the path changes between runs, old TMA versions accumulate and registration breaks.

After installation, register the add-in machine-wide under HKLM so all user accounts inherit it:

HKLM\Software\Microsoft\Office\Outlook\Addins\TeamsAddin.FastConnect
  LoadBehavior   (DWORD)  = 3
  Description    (String) = Microsoft Teams Meeting Add-in for Microsoft Office
  FriendlyName   (String) = Microsoft Teams Meeting Add-in for Microsoft Office

If your environment uses AppLocker or MSI install restrictions, you must add an exception for the TMA installer path:

FilePathCondition Path="%PROGRAMFILES%\WINDOWSAPPS*\MICROSOFTTEAMSMEETINGADDININSTALLER.MSI"

RDS image checklist#

• Set the VDI environment flag. HKLM\Software\Microsoft\Teams\IsWVDEnvironment = 1 (DWORD). This tells Teams to use the machine-wide install model instead of trying per-user installs at logon.
• Disable Teams auto-update on the image. Set HKLM\SOFTWARE\Microsoft\Teams\disableAutoUpdate = 1 (DWORD) on the base image. Update Teams and re-run TMA install as a deliberate step during image maintenance, not on live sessions. When this key is present, teamsbootstrapper.exe -p alone will not install TMA, you must include --installTMA explicitly.
• Confirm WebView2 is present and current. New Teams requires Microsoft Edge WebView2. If it is missing or outdated, Teams will not launch correctly and TMA registration will fail silently.
• Verify Windows Server 2022 build. Your server build must be 20348.2402 or later. Earlier builds are below Microsoft's stated minimum for new Teams on VDI and can produce unpredictable registration behaviour.
• Add Teams to your antivirus and DLP exclusions. Security software that intercepts or scans Teams processes at launch can silently block TMA registration. Add Teams to your antivirus and data loss prevention exclusion lists before sealing the image. This is a Microsoft requirement for Teams on VDI.
• Persist the required Teams profile paths. These paths must roam with the user profile or Teams state is lost on every logoff. The key file for TMA is AppData\Local\Publishers\8wekyb3d8bbwe\TeamsSharedConfig\tma_settings.json. Do not persist the meeting-addin folder under TeamsSharedConfig. Persisting it causes incorrect meeting coordinates in Outlook templates.
• Validate in a non-admin session. Log in as a standard user, open Outlook, then go to File > Options > Add-ins. The Teams Meeting Add-in should appear under Active Application Add-ins, pointing to the current version path.

Quick confirmation and troubleshooting#

How do I confirm that error 1625 is the cause?#

On a non-admin session, open Event Viewer and go to Windows Logs > Application. Filter for Source: MsiInstaller. Look for Event ID 1625 around the time of the last logon. If you see it, the per-user TMA installer was blocked by system policy. Machine-wide HKLM registration is the fix.

Why does the add-in show as inactive in Outlook?#

Outlook disables add-ins that fail to load within a set time. If TMA is registered to a path that no longer exists (the old version folder after a Teams update), Outlook marks it as a slow or crashed add-in and disables it automatically.

Fix the registration to point at the correct current path, then re-enable the add-in under File > Options > Add-ins > Manage COM Add-ins.

Do I need to re-run anything after each Teams update?#

Yes, if you use Option B (MSI method). Each Teams update ships a new TMA version in a versioned subfolder. Your deploy script needs to detect the new version path and update both the file install target and the HKLM registry path accordingly.

Option A (bootstrapper) handles this for you. teamsbootstrapper.exe -p --installTMA always installs the TMA version that matches the Teams build on the machine, so re-running it after an update is enough.

Bootstrapper is failing with an error code. What do I check?#

Check Event Viewer under Applications and Services Logs > Microsoft > Windows > AppXDeployment-Server for detailed output. Three common codes:

• 0x80070057: The bootstrapper command is using a relative path (with a dot). Use the full path to the MSIX instead, for example c:\temp\MSTeams-x64.msix.
• 0x80070032: Probable UNC path issue. Copy the MSIX to a local folder and try again.
• 0x80004004: A leftover registry key maglevInstallationSource at HKLM\Software\WoW6432Node\Microsoft\Office\Teams is blocking the install. Delete it and retry.

TMA is installed but presence is not showing in Outlook. What do I check?#

Outlook presence relies on Teams being registered as the default instant messaging app. Make sure Teams is running first, then launch Outlook. The order matters.

Then check the following registry values under the affected user account:

HKCU\Software\IM Providers
  Name: DefaultIMApp | Type: REG_SZ | Data: MsTeams

HKCU\Software\IM Providers\MsTeams
  Name: UpAndRunning | Type: REG_DWORD | Data: 2 (0 = not running, 1 = starting, 2 = running)

If either value is missing or wrong, Teams did not complete its registration with Office. Signing out of Teams and signing back in while Outlook is closed will usually re-stamp them.