Finding in the Wild | Citrix MCS – Windows Rearm Failure After November 2026 Updates

I’ve recently encountered the same issue at two of my customers:

After installing the November 2026 Windows updates, image preparation through Citrix Machine Creation Services (MCS) fails.

And apparently, I’m not the only one. Several administrators have reported similar issues in the comments on Günter Born’s blog.

⚠️ Windows Updates Under Investigation:

  • Windows Server 2019 – KB5131085
  • Windows Server 2022 – KB5131090
  • Windows Server 2025 – KB5131080

🔍 The Issue

MCS image preparation fails with the following error:

Image preparation failed to rearm the copy of Windows installed on the master image.

As a result, the updated master image cannot be deployed successfully.

🔬 Technical Analysis

The failure occurs during the Windows rearm operation as part of the MCS image preparation process.

Whether this is caused by changes to the Windows Software Protection Service, Windows activation mechanisms, or the interaction between Windows and Citrix MCS remains unclear.

The timing strongly suggests a connection to the November Patch Tuesday updates, but correlation alone does not establish the root cause.

🛠️ My Recommendations

1️⃣ Install the November updates on test master images first.

2️⃣ Validate the complete MCS image preparation process — not just whether Windows boots successfully.

3️⃣ If preparation fails, investigate Citrix ProvTask details, preparation VM logs, and Windows activation events.

4️⃣ Keep the last known-good master image snapshot available for rollback.

5️⃣ Postpone production Machine Catalog updates until the updated image has been successfully validated.

I would also avoid manually modifying slmgr /rearm or Windows activation settings until the underlying cause has been identified.

❗ Current Status

I’ve reproduced this issue in two customer environments, and several similar reports have appeared in the community.

As of now, there is no official confirmation or documented fix from Citrix or Microsoft.

Has anyone identified a reproducible root cause or a working workaround?

I’m particularly interested in the CVAD versions and Windows activation methods (KMS, MAK, or ADBA) used in affected environments.

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 | StoreFront + Entra ID Is Becoming Seriously Interesting

During a current Citrix project, I came across a development that will be particularly interesting for future StoreFront architectures. StoreFront can now configure Microsoft Entra ID directly through the management console. This becomes especially interesting in hybrid environments:

During a current Citrix project, I came across a development that will be particularly interesting for future StoreFront architectures.

StoreFront can now configure Microsoft Entra ID directly through the management console.

This becomes especially interesting in hybrid environments:

→ Hybrid users can receive resources from Citrix DaaS and on-premises CVAD through StoreFront.

→ From CVAD 2603, StoreFront supports Entra ID SSO to published resources, provided the VDAs are appropriately hybrid Entra ID joined.

→ Even more interesting: Entra SSO and FAS can be used in parallel within the same store.

StoreFront uses each delivery group’s logon type to decide which authentication method to use for resource launch.

For example, this enables gradual modernization of an environment without immediately removing FAS from the design.

What I take from this for new designs

In future, I would create an authentication matrix during the design phase:

Delivery group → VDA join state → authentication method → SSO method

For example:

• Conventional AD VDAs → FAS
• Hybrid Entra ID joined VDAs → Entra SSO
• DaaS workloads → according to the identity design

In larger hybrid environments in particular, this prevents considerable confusion later.

For me, this is another step towards making StoreFront more interesting in modern Entra ID/DaaS architectures, rather than viewing it solely as a component of conventional on-premises CVAD environments.

Finding in the Wild | Secure Boot 2026 – A Topic That Belongs in VDI Master Images

Microsoft continues preparing the transition away from expiring Secure Boot certificates. This is already relevant for conventional clients, but virtualized environments add another layer. Especially with Windows 11 and Windows Server 2025, I would therefore incorporate this topic

Microsoft continues preparing the transition away from expiring Secure Boot certificates.
This is already relevant for conventional clients, but virtualized environments add another layer.
Especially with Windows 11 and Windows Server 2025, I would therefore incorporate this topic into image and provisioning processes now.

A few basic checks:

In VDI environments, also check:
🔹 UEFI configuration
🔹 vTPM and hypervisor
🔹 Firmware level
🔹 BitLocker and recovery process
🔹 Master image and templates
🔹 MCS and PVS provisioning

The crucial point: with non-persistent and provisioned systems, examining only individual VMs is not enough.
When Secure Boot changes are required, it must be clear how those changes propagate through the master image, hypervisor and provisioning to the actual VDAs.

For new Windows 11 VDI and Windows Server 2025 environments in particular, I would therefore include this topic directly in the technical baseline.

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. 😉