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 | Citrix – ICA Session Started, but No Desktop Is Visible

An issue that can quickly send Citrix troubleshooting in the wrong direction: The user launches a virtual desktop using a downloaded ICA file. The connection starts, but Citrix Desktop Viewer does not appear. ❌ No visible desktop ❌

An issue that can quickly send Citrix troubleshooting in the wrong direction:

The user launches a virtual desktop using a downloaded ICA file. The connection starts, but Citrix Desktop Viewer does not appear.

❌ No visible desktop
❌ No clear error message
❌ Launching the session again does not necessarily help
✅ The session may already exist on the VDA

🔍 Root cause – HDX-97520

Under HDX-97520, Citrix documents a client-side issue when launching sessions through downloaded ICA files.

The key distinction: a successfully established ICA connection does not automatically mean that the corresponding Desktop Viewer interface is displayed.

The cause is therefore not necessarily the Delivery Controller, VDA or StoreFront.

🛠️ My troubleshooting approach

1. Check the client

First, I check the installed Citrix Workspace App and deliberately relaunch the downloaded ICA file.

I check whether wfica32.exe starts and whether Desktop Viewer is visible.

2. Check the session on the server side

Using Citrix Director or PowerShell, I check whether the user already has a session on the VDA.

If the session exists but no desktop is visible, I focus on the client side.

3. Analyze logs and processes

* Workspace App version and ICA launch method
* wfica32.exe and Desktop Viewer processes
* Citrix Workspace App diagnostic logs
* Windows application events
* Session status on the VDA

✅ The fix

Citrix lists HDX-97520 among the fixed issues in Citrix Workspace App 2607 LTSR for Windows.

My approach: update an affected endpoint, then retest ICA launch and the Desktop Viewer display.

💡 My takeaway

A user seeing no desktop does not automatically mean that Citrix failed to establish a session.

Combining client diagnostics with a server-side session check reveals where the issue actually lies.

Finding in the Wild | NetScaler 14.1-73.33+ – Security Patch Installed, and Suddenly the ICA Session Is Gone?

Many NetScaler administrators are currently likely to be updating their appliances to 14.1-73.33 or later because of current security issues. And, of course, the recommendation remains: 👉 Install security updates! However, the release notes contain a small detail

Many NetScaler administrators are currently likely to be updating their appliances to 14.1-73.33 or later because of current security issues.

And, of course, the recommendation remains:

👉 Install security updates!

However, the release notes contain a small detail worth knowing before the maintenance window.

ICA Proxy sessions may lose their ability to reconnect

The scenario:

A user starts a Citrix session before the NetScaler upgrade.

The session continues running on the VDA.

The NetScaler is then updated to 14.1-73.33+.

When the user subsequently tries to reconnect to the existing session:

💥 Reconnect fails.

The reason is the session tickets issued before the upgrade.

They can no longer be used for reconnection after the upgrade. The user must start a new session.

The good news:

This is not a general ICA Proxy issue after the upgrade.

Sessions started after the upgrade work normally, including subsequent reconnects.

No additional configuration is required.

The affected transition is:

Pre-upgrade session → upgrade → post-upgrade reconnect

Why does this matter?

We normally perform NetScaler HA upgrades with as little user impact as possible:

Upgrade secondary → failover → upgrade primary.

It is easy to assume:

HA upgrade without downtime = users notice nothing.

That is not necessarily true here.

The infrastructure may be fully available while existing ICA sessions are still affected at the next reconnect.

🔥 Zero-downtime HA upgrade ≠ zero user impact

My recommendation

When upgrading to 14.1-73.33+:

👉 Account for existing ICA sessions
👉 Inform users about possible session loss
👉 Prepare the service desk accordingly
👉 Perform the upgrade outside productive usage hours where possible

This small detail can become particularly relevant in 24/7 environments.

Takeaway

Of course, this is no reason to postpone a security update.

But it demonstrates again:

Sometimes the most interesting findings are not in the security bulletin, but somewhere in the release notes. 😉

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 | Citrix MCS + Nutanix AHV – No More Than 10 VMs per Batch

Yesterday, during a Citrix MCS project with Nutanix AHV / Prism Central, I encountered some interesting behavior. Adding a larger number of VMs to an MCS machine catalog may fail with: OutOfMemory . Initially, I suspected resource issues

Yesterday, during a Citrix MCS project with Nutanix AHV / Prism Central, I encountered some interesting behavior.

Adding a larger number of VMs to an MCS machine catalog may fail with:

OutOfMemory

.

Initially, I suspected resource issues on Nutanix or in the Citrix infrastructure. However, Citrix already knows about the issue and documents it under PMCS-58254.

Citrix currently explicitly recommends:

👉 Add no more than 10 VMs to an MCS catalog at a time.

The workaround is correspondingly simple: for larger rollouts, create machines in batches of no more than 10 VMs.

Interestingly, the issue is documented not only in the new release, but also for 2507 LTSR and Citrix DaaS.

Another small Citrix detail that never appears with five VMs but may suddenly cost significant time during a larger rollout. 😉