Tag: Remote Desktop 29 posts

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 | A New Edge Security Baseline – and Your Browser Integration Suddenly Stops Working?

Microsoft has released the new Security Baseline for Microsoft Edge 151. Normally, that initially sounds like: New version → new ADMX → update baseline → done. This time, however, I would look more closely in Citrix and RDS

Microsoft has released the new Security Baseline for Microsoft Edge 151.

Normally, that initially sounds like:

New version → new ADMX → update baseline → done.

This time, however, I would look more closely in Citrix and RDS environments.

Microsoft includes several new recommendations. One is particularly interesting:

👉 Process Isolation

What is behind it?

Process Isolation aims to prevent other local processes from interfering with Microsoft Edge or manipulating browser processes.

Entirely understandable from a security perspective.

However, enterprise environments have plenty of software that operates exactly at this point.

For example:

DLP / endpoint security / SSO / monitoring / browser integrations / legacy agents

And this is where it becomes interesting for Citrix.

On a normal client, it affects one user.

On a multi-session VDA with 30, 50 or more users, a small browser baseline change may suddenly affect many sessions simultaneously.

A typical scenario

New Edge ADMX files are added to the Central Store.

The new Security Baseline is applied to the Citrix VDAs.

Edge starts.

Websites work.

Test successful?

Not necessarily. 😉

The interesting part is the integrations:

👉 Does SSO still work?
👉 Do DLP/security components work?
👉 Do browser extensions work?
👉 Do internal web applications work?
👉 Are there sudden errors or unusual processes?

Another point: Automatic HTTPS

Microsoft also recommends evaluating Automatic HTTPS.

That initially sounds sensible too.

However, anyone still running internal applications accessible only through HTTP should be cautious with aggressive upgrade modes.

Experience shows that older Citrix environments still contain quite a few of these. 😎

My recommendation

A new browser Security Baseline should not go straight into the production golden image.

First:

Baseline diff → test VDA → security/SSO/DLP → internal web apps → multi-session test → production

And if Process Isolation causes problems:

Do not simply disable the policy again.

First determine which software is trying to interfere with the browser process.

That may be the actual finding.

Takeaway

Security Baselines are not collections of settings to simply switch to Enabled.

Especially on Citrix multi-session VDAs, small browser changes can have a substantial impact.

Hardening without compatibility testing is another way to prepare for future troubleshooting. 😉

Finding in the Wild | Windows October Update Breaks Citrix VDA Registration

A new Patch Tuesday, a new surprise. This time, Citrix VDA registration is affected. After installing Windows 11 security update KB5127648 (October 2026), Citrix Virtual Delivery Agents may suddenly fail to register with the Delivery Controller. The interesting

A new Patch Tuesday, a new surprise. This time, Citrix VDA registration is affected.

After installing Windows 11 security update KB5127648 (October 2026), Citrix Virtual Delivery Agents may suddenly fail to register with the Delivery Controller.

The interesting part: the VDA is reachable and RDP works, but Citrix remains stuck at Registering.

🔍 The symptoms
– Citrix Studio: Trying to re-register
– VDA status remains at Registering
– Published desktops cannot be launched
– RDP to the affected machine still works

Citrix officially documents the issue under CTX697231 for Windows 11 24H2/25H2, reported with VDA 2511. Other VDA versions may also be affected.

🔬 The decisive clue is in the event log

On the Delivery Controller:
Event ID 131075
Process: BrokerService.exe
Exception:
System.ServiceModel.Security.SecurityNegotiationException
Error message:
The caller was not authenticated by the service.
Affected operation:
Citrix.Cds.Protocol.Worker.IQueryAgent.Test()

This is where it gets interesting: the problem is not basic Controller connectivity, but authentication during communication between the Broker Service and VDA.

🛠️ The workaround

Citrix has already published a tested mitigation:

Then restart the affected VDA.

The registry value switches from the new Windows Administrator Protection to classic Admin Approval Mode.

Citrix confirms that affected VDAs register successfully again afterwards.

⚠️ Important: this is a temporary workaround that rolls back an additional Windows security feature. Apply the change in a controlled manner and reassess it after a permanent fix becomes available.

💡 What can we learn?

A VDA that fails to register after Patch Tuesday does not necessarily have a Citrix issue.

And working RDP does not mean that Citrix Broker authentication is working too.

Before reinstalling VDAs, repairing Delivery Controllers or dismantling the Active Directory configuration:

Check KB5127648, Event ID 131075 and TypeOfAdminApprovalMode.

Citrix and Microsoft continue to investigate the underlying cause together.

📚 Source:

Windows 11 KB5127648 Causes Citrix VDA Registration Failure
Windows 11 KB5127648 Causes Citrix VDA Registration Failure

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:

Installing New Microsoft Teams (Version 2) in Citrix
The new version of Microsoft Teams, often called Teams 2.0, has been the new standard since July 1, 2024. For VDI environments, this means there is no going back.

Finding in the Wild | Citrix Entra SSO – When the Microsoft Security Baseline Blocks Sign-In

A Citrix environment with Microsoft Entra ID, correctly configured SSO and registered VDAs. Users authenticate successfully to Citrix Workspace. However, launching the desktop prompts for Windows credentials again, or SSO fails. The symptoms: ✅ Entra ID authentication succeeds

A Citrix environment with Microsoft Entra ID, correctly configured SSO and registered VDAs.

Users authenticate successfully to Citrix Workspace. However, launching the desktop prompts for Windows credentials again, or SSO fails.

The symptoms:

✅ Entra ID authentication succeeds
✅ The VDA is registered and reachable
✅ Citrix resources are displayed
❌ Single sign-on within the session does not work

The initial suspects are Entra ID, Conditional Access, Kerberos or the Citrix configuration.

But the actual cause may lie in a Microsoft Security Baseline.

🔍 Root cause

Citrix Entra SSO requires the following Windows security setting:

Allow Custom SSPs and APs to be loaded into LSASS

The Microsoft Intune Security Baseline for Windows sets this setting to Disabled by default.

This prevents Windows from loading additional Security Support Providers and Authentication Packages into LSASS.

As a result, the authentication integration required for Citrix SSO can be blocked.

🛠️ My troubleshooting approach

First, I check the effective policy on the affected VDA:

Computer Configuration → System → Local Security Authority

The critical setting is:

Allow Custom SSPs and APs to be loaded into LSASS

Next, I check whether Intune, a Security Baseline or a conventional GPO controls this setting.

The solution:

Specifically set the setting to Enabled on the affected Citrix session hosts.

Important: do not disable the entire Security Baseline!

I would use a dedicated policy or an agreed exception for the Citrix VDAs.

Then verify policy application, restart the VDA and retest SSO.

⚠️ Security note

This change permits additional SSP/AP components to load into LSASS, deliberately expanding the allowed authentication integration.

The exception therefore belongs only on systems that actually require this functionality.

💡 My takeaway

Not every Citrix SSO issue is a Citrix problem.

Sometimes a correctly deployed Security Baseline prevents exactly the functionality required by the intended authentication architecture.

Security hardening and functionality must be considered together, especially with Citrix, Entra ID and Windows.