Finding in the Wild | Teams Meeting Button Missing in Outlook – Even Though the Add-In Is Active?

An interesting issue appeared in a current Windows Server 2022 multi-user environment: ✅ Microsoft Teams Meeting Add-in was installed ✅ Outlook showed the add-in as active ✅ TeamsAddin.FastConnect reported Connect = True ❌ Yet the Teams button was

An interesting issue appeared in a current Windows Server 2022 multi-user environment:

✅ Microsoft Teams Meeting Add-in was installed
✅ Outlook showed the add-in as active
✅ TeamsAddin.FastConnect reported Connect = True
❌ Yet the Teams button was missing from the Outlook calendar

The cause was no longer COM registration, but a missing configuration file:

Without this file, the Outlook add-in cannot reliably recognize New Teams as the active Teams client. The add-in loads, but does not fully initialize the calendar area.

The solution was to create the file with the following content:

Then:

– Close Teams and Outlook
– Start Teams first and sign in
– Then open Outlook

The Teams meeting button was available in the calendar again afterwards.

Particularly important for Citrix, RDS and FSLogix environments:

The following path should persist in the user profile and must not be lost through exclusions or profile cleanup:

AppData\Local\Publishers\8wekyb3d8bbwe\TeamsSharedConfig

A small missing JSON file with a big impact: a classic Microsoft 365 moment. 😉

Finding in the Wild | CWA CleanInstall & Teams SlimCore

During a recent Citrix Workspace App update , I encountered interesting behavior involving Microsoft Teams SlimCore . The Microsoft Teams VDI Plugin was already installed on the client. Workspace App was then updated using /CleanInstall . Initially, everything

During a recent Citrix Workspace App update, I encountered interesting behavior involving Microsoft Teams SlimCore.

The Microsoft Teams VDI Plugin was already installed on the client. Workspace App was then updated using /CleanInstall.

Initially, everything looked fine:
Citrix Workspace App ✔️
Teams VDI Plugin ✔️
Software deployment ✔️

Nevertheless, SlimCore optimization no longer worked.

The investigation revealed that the required DLLs were no longer present in the ICA Client directory, although the Teams VDI Plugin still appeared as installed under Apps & Features.

That is precisely what makes this issue interesting.

If an automated CWA update checks only installation status, you get a successful deployment even though the actual Teams optimization no longer works.

For my update tests, this means:
CWA version → Teams VDI Plugin → DLLs → SlimCore → actual optimization mode
must be checked together.

Especially with the increasing move to SlimCore, I believe this functional test should be part of a CWA/Teams update.

👉 Finding in the Wild: installed does not automatically mean operational.

These issues are exactly why I do not just install Citrix updates, but also check the relevant functions afterwards.

Finding in the Wild: I will keep investigating.

Finding in the Wild | Teams Warns That VDI Optimization Is Ending – but Not Every Endpoint Needs SlimCore Yet

Users of classic Citrix HDX/WebRTC optimization are currently seeing a prominent message in Microsoft Teams: “Teams optimization for your virtual desktop will soon be unsupported.” The problem: There apparently is no documented way to suppress this warning administratively

Users of classic Citrix HDX/WebRTC optimization are currently seeing a prominent message in Microsoft Teams:

“Teams optimization for your virtual desktop will soon be unsupported.”

The problem:
There apparently is no documented way to suppress this warning administratively at present.

The result is predictable:
👉 Users see the message.
👉 Users contact the help desk.
👉 Yet immediate action is not required everywhere.

Microsoft distinguishes between endpoint platforms for the end of support:

🪟 Windows endpoints
The previous WebRTC-based optimization reaches end of support on October 1, 2026. Here, the direction is towards SlimCore.

🐧 Linux thin clients such as IGEL
are explicitly exempt from this date. The existing optimization remains supported until the corresponding new VDI optimization is available for Linux.

This creates an interesting situation in mixed environments:

Windows → SlimCore
IGEL/Linux → existing optimization continues

Community reports now suggest that Microsoft is aware of the warning issue and is allegedly working on a way to suppress it.

However, this is not yet officially documented.

For me, this is another example of a technically correct warning not necessarily producing a good user experience. 😉

Anyone running Windows alongside IGEL/Linux should therefore not overturn their entire Teams VDI strategy based solely on this popup.

Finding in the Wild | Microsoft Teams Is Installed, but Unavailable to the User

An issue I encounter repeatedly in Citrix VDI environments: Microsoft Teams is installed in the master image and works for the administrator. After MCS or PVS provisioning, however, users cannot start Teams. ❌ Teams is missing from the

An issue I encounter repeatedly in Citrix VDI environments:

Microsoft Teams is installed in the master image and works for the administrator. After MCS or PVS provisioning, however, users cannot start Teams.

❌ Teams is missing from the Start menu
❌ The application does not start
❌ Only some users are affected
❌ Reinstallation helps only temporarily

The cause? Often, missing MSIX registration in the user context.

New Teams is based on MSIX. System-wide provisioning and per-user registration must be distinguished.

An installed package does not automatically mean Teams is available to every user.

🔍 1️⃣ Check Teams provisioning

2️⃣ Registration in the user context

3️⃣ Analyze AppX errors

🛠️ 4️⃣ My workaround: register Teams again at logon

At several customers, I was able to resolve the issue by registering Teams again during user logon.

Run a scheduled task in the user context:

The command registers the already provisioned Teams package again for the signed-in user.

Important: the task must run in the relevant user’s context. It does not replace missing system-wide Teams provisioning.

🔧 5️⃣ FSLogix and Citrix UPM

Also check the following settings:

✔ FSLogix InstallAppxPackages
✔ Current FSLogix/UPM versions
✔ UWP app roaming in Citrix UPM
✔ AppX/MSIX permissions
✔ DisableAppInstallsOnFirstLogon
✔ Profile persistence and exclusion lists

The logon task is an effective workaround for missing user registration. In the longer term, however, the cause in profile management or the AppX registration process should be addressed.

💡 My takeaway

Installed ≠ provisioned ≠ registered.

In non-persistent Citrix environments in particular, registering Teams again at logon can make the decisive difference.

I have published a complete guide to installation, optimization, profile configuration and troubleshooting here:

Finding in the Wild | Citrix – When the Teams VDI Plugin Prevents ICA Launch

An interesting issue from the Citrix world: After installing or updating the Microsoft Teams VDI Plugin, Citrix applications and desktops suddenly fail to launch. ❌ ICA launch fails ❌ Applications and desktops do not start ❌ StoreFront and

An interesting issue from the Citrix world:

After installing or updating the Microsoft Teams VDI Plugin, Citrix applications and desktops suddenly fail to launch.

❌ ICA launch fails
❌ Applications and desktops do not start
❌ StoreFront and Delivery Controllers may still be reachable
❌ The issue appears only after the plugin is installed

🔍 Root cause – CVADHELP-34806

Citrix documents an issue in which installing the Microsoft Teams VDI Plugin can corrupt the VirtualDriverEx registry value.

This value is part of the Citrix ICA Client Engine configuration and is used to register additional virtual channel components.

If it is corrupted, the ICA session may fail to start.

🛠️ My troubleshooting approach

First, I check whether the issue coincides with a Teams VDI Plugin update.

Next, I check the following on the endpoint:

* Workspace App and Teams VDI Plugin versions
* The VirtualDriverEx registry value
* Differences compared with a working reference client
* Workspace App logs and the ICA launch process

The key check:

Read and compare the VirtualDriverEx value at this location.

✅ The fix

Citrix resolved the issue in Workspace App 2507.1 LTSR CU3 Hotfix 1.

My approach:

1. Back up the registry configuration before making changes.
2. Update the affected endpoint to the corrected Workspace App build.
3. Check the Teams VDI Plugin and virtual channel registration.
4. Retest ICA launch and Teams optimization.

Do not blindly copy registry values from other systems or permanently disable Teams optimization.

💡 My takeaway

When Citrix sessions suddenly fail to start, the cause is not necessarily the VDA, Broker or StoreFront.

Sometimes a faulty registry entry on the endpoint is enough to prevent the entire ICA launch.

A Teams plugin can therefore cause a Citrix launch failure long before Teams is even opened.