Tag: Workspace App 9 posts

Finding in the Wild | Citrix Workspace App + IGEL – BadWindow in Multi-Monitor Setups

At a customer, I encountered an interesting issue with Citrix Workspace App on IGEL OS. The symptoms: In a multi-monitor configuration, individual Citrix windows occasionally misbehaved. The session itself generally worked, but the logs showed X11 errors such

At a customer, I encountered an interesting issue with Citrix Workspace App on IGEL OS.

The symptoms:

In a multi-monitor configuration, individual Citrix windows occasionally misbehaved. The session itself generally worked, but the logs showed X11 errors such as:

BadWindow
BadDrawable
BadGC

After some investigation, I narrowed the issue down to the interaction between IGEL OS, Citrix Workspace App and X11 window handling.

One interesting parameter provided by IGEL for Citrix Workspace App is:

app > cwa > wfclient > thinwire30 > ignorexerrors

Specific X11 errors can be ignored there using values such as

20.0/3, 55.0/9, 60.0/13

.

This mitigated the behavior in my case.

But be careful: this is not a true fix for the underlying cause.

IgnoreXErrors causes the relevant X11 errors to be ignored. These errors also stop appearing in the logs.

That must be considered during troubleshooting. A clean log afterwards does not automatically mean the underlying cause has disappeared.

My learning from this case:

If Citrix generally works on an IGEL endpoint but unusual window issues occur, particularly with multiple monitors, examine the CWA/X11 logs.

BadWindow, BadDrawable or BadGC can be useful clues.

And before dismantling the VDA, HDX Graphics or the entire Citrix infrastructure:

Check the endpoint first. 😉

Finding in the Wild | Citrix Workspace App 2603.11 x64

I came across an interesting issue with the native 64-bit version of Citrix Workspace App 2603.11 . This is particularly interesting because 2603.11 is also one of the builds Citrix recommends updating to because of CVE-2026-78546 and CVE-2026-78547.

I came across an interesting issue with the native 64-bit version of Citrix Workspace App 2603.11.

This is particularly interesting because 2603.11 is also one of the builds Citrix recommends updating to because of CVE-2026-78546 and CVE-2026-78547.

After the update, under certain conditions:
❌ Published applications and desktops may fail to start
❌ Domain pass-through authentication against StoreFront may fail
❌ Users may suddenly receive a credential prompt

The cause is related to a missing or incorrect reference to the 64-bit cck.dll.

Citrix has now documented a workaround:

The following value must exist there:
Name: X64
Type: REG_SZ
Value: C:\Program Files\Citrix\ICA Client\Receiver\cck.dll

Via command line:

Citrix plans to include the fix in an upcoming 2603 release.

💡 The interesting part:
Security says: Upgrade to 2603.11 or later.

Operations says: Not without testing, especially with StoreFront + domain pass-through.

These are exactly the small details that are easy to overlook in a test environment and then cause trouble during a broad client rollout. 😉

Finding in the Wild: Anyone currently upgrading to CWA 2603.11 x64 should explicitly test app/desktop launch and domain pass-through.

Finding in the Wild | Citrix Workspace on macOS 27 – Sign-In Fails After an Update

After upgrading to macOS 27 , I encountered an interesting issue with Citrix Workspace App . After entering the store URL, the following error appears: The URL specified in the provisioning file cannot be contacted. The initial suspects

After upgrading to macOS 27, I encountered an interesting issue with Citrix Workspace App.

After entering the store URL, the following error appears:
The URL specified in the provisioning file cannot be contacted.

The initial suspects are, of course:
– StoreFront
– NetScaler
– DNS
– Firewall
– Certificates

In this case, however, the cause lay somewhere completely different.

Cause

Under
System Settings → Privacy & Security → Local Network
, the entry ServiceRecords was disabled.

After enabling the permission, sign-in immediately worked again.
✅ The store could be added
✅ Username and password were accepted
✅ Workspace App worked normally again

Why this is interesting

The error message suggests a network or StoreFront problem.

In reality, macOS blocks Workspace App’s local network communication, causing discovery to fail.

Especially after upgrading to macOS 27, it is worth checking privacy settings before starting to:
– Analyze StoreFront
– Check NetScaler
– Replace certificates
– Capture network traces

Sometimes the cause is much closer than expected.

Has anyone else observed this behavior after upgrading to macOS 27?

Finding in the Wild | Citrix Workspace App 2607 LTSR x64 – StoreFront SSO Stops Working

A Citrix Workspace App upgrade, and suddenly automatic sign-in to StoreFront stops working. These issues are particularly interesting because the cause is not necessarily where you first expect it. The symptoms: ❌ Windows logon works normally ❌ StoreFront

A Citrix Workspace App upgrade, and suddenly automatic sign-in to StoreFront stops working.

These issues are particularly interesting because the cause is not necessarily where you first expect it.

The symptoms:

❌ Windows logon works normally
❌ StoreFront requests a username and password again
❌ Domain pass-through authentication no longer works
✅ SSO worked before switching to the native x64 Workspace App

The first suspects are often Kerberos, GPOs, StoreFront or the SSON component.

The actual cause:

Citrix documents a known issue with domain pass-through authentication in Workspace App 2607 LTSR x64.

Registration of the cck.dll component may be missing or incorrect in the 64-bit registry branch.

🛠️ The workaround

On the affected client, registration can be corrected using the following command:

Then exit Workspace App completely and test the sign-in again.

My takeaway:

If StoreFront SSO suddenly fails after a Workspace App upgrade, I would not immediately dismantle the entire authentication chain.

First, I check the client version, architecture and registration of the components involved.

A small registry entry can make the decisive difference here.

⚠️ This workaround applies to the documented symptoms and should be tested before a broad rollout.

Finding in the Wild | Citrix Workspace App 2610 – A Client Update with Side Effects?

A new Citrix Workspace App release initially sounds routine. However, version 2610 introduces changes that can quickly become relevant during larger client rollouts. And this time, it is not just about new features. 🔍 What has changed? Citrix

A new Citrix Workspace App release initially sounds routine.

However, version 2610 introduces changes that can quickly become relevant during larger client rollouts.

And this time, it is not just about new features.

🔍 What has changed?

Citrix Workspace App 2610 changes its runtime dependency from .NET 8 to .NET 10.

This means that installation may require and install an additional or updated .NET runtime.

Organizations using centralized software distribution through Intune, Configuration Manager or other deployment solutions should account for this change.

⚠️ The real challenge: x86 → x64

When migrating from a 32-bit Workspace App to a native 64-bit version, older third-party virtual channel plugins may become a problem.

Citrix therefore performs compatibility checks.

Possible results are recorded at the following path:

C:\Program Files\Citrix\Logs\IncompatibleThirdPartyPlugins.json

If an incompatible plugin is detected, automatic migration may be blocked.

Citrix does provide the parameter:

/SkipThirdPartyVCCheck

But be careful: this parameter only skips the check. It does not make incompatible plugins compatible.

🛠️ What I would check before a rollout

✅ Inventory existing x86 virtual channel plugins

✅ Account for .NET 10 dependencies in software distribution

✅ Test Teams, Webex, scanner and peripheral integration

✅ Validate silent installation, upgrade and rollback

✅ Check GACS policies after the update

💡 My takeaway

A Workspace App update is not automatically just a client update.

Once runtime dependencies, architecture and virtual channels are involved, an apparently simple version change can become a compatibility problem.

Especially with several hundred endpoints, I would not deploy it broadly straight away.

Test first. Then migrate.