Citirx Remote Desktop Icons when using XMLBroker...

Hi,

 

 

We also serve app-specific icons on Webtop for every published application. Though it's supported properly on IE8 and later (and Firefox/Chrome).

 

 

Do you happen to know if your users access APM using IE6/7?

 

 

If they're all on IE8 or other browsers, I strongly suggest to contact F5 Support because it's likely a bug.

I have seen this. I am pretty sure, at least with 11.1, the APM only supported 32x32 32bpp icons. Check the icons and see. The client I was working with had to modify some of their icons on the XMLB Side.

It kind of looks like a bug... Looking deeper into the tcp stream between the BigIP APM and the XMLBroker, and I see 3 requests for icon data. One for Adobe Reader (Works), one for a remote desktop something (Works), and one for Calculator (I get a lot of icon data back, but no icon shown).

 

 

After the calculator, there's no more icon data requested from the XMLBroker...

 

 

This is running 11.2HF2 (HF2 had a fix in there for not displaying icons... I wonder if it wasn't quite fixed properly).

 

 

H

Hamish,

 

What version of XenApp are you using? Sounds like you have gathered a lot of troubleshooting data already - it would be great if you can open a case, and F5 support can then help you resolve this issue.

 

Case opened today. First response is known problem, upgrade to HF2... Sadly for support, I'm already at HF2 :) So hopefully they'll read the tcpdump I gave them and come up with a solution. Funnily enough, the bpp=4 icons work.. The 32bpp icon of the Calculator app is what seems to brake it.

 

 

I also found another hit in a SOL note regarding XenApp 4.5... (WHich we're running). It has a work-around that relies on a registry change and a reboot. Our Citrix admin is going to do that for me tonite on a test server and we'll see how that goes. The SOL note says it's something to do with chunking of the icon data and not sticking to RFC specs quite close enough (Is there an IBM engineer in there somewhere? They used to have issues where sent data wasn't quite RFC compliant in products where others took it fine - e.g. Multicast in AIX :)

 

 

H

Was the XenApp bug in 4.5... The work-around originally killed the test xenapp server, but the admins fixed that, and I have icons again. Much nicer... Would be nice if APM didn't freak for a single bad response and disable ALL subsequent icons though...

 

 

I've been playing around to try & fixup the stream on the internal BigIP VS (Running two layer as in the whitepaper), but no luck so far (The explanation for headers given doesn't seem to jive... Because if you fixup the headers, it still doesn't work without the xenapp server work-around. Does APM just have issues with chunked icon data? Because the workaround only seems to stop the chunking. not change any headers).

 

 

H

Hamish,

 

 

There are two issues that cause the problem with XenApp 4.5

 

 

The response from 4.5 XML broker violates HTTP standard in two ways:

 

1) It has 'Transfer-Coding' header instead of 'Transfer-Encoding' <-- this one is easy to fix with iRules

 

2) It does not have a trailing CRLF as dictated by RFC. <-- this one is not so easy and requires layered virtuals and non-the-shortest iRule to fix - so getting it done on the XenApp server itself is the best way to go.

 

 

Hope it helps.

 

 

Hi Michael.

 

 

Do you know exactly where the trailing CRLF is missing from? (A glutton for punishment, me) As you say, fixing the headers is easy. But I can't actually find where there's any missing CRLF's in the icondata response (Looking at the one that is requested by not displayed).

 

 

Although the work-around does work, the description of it is actually not a 100% match. The SOL note mentions missing apps... but all the apps are there on mine. It's just the icons that are missing. Three are requested and display correctly. The third is requested, and returned, but not displayed. APM then doesn't bother to request any more icons. It's a bit strange to me that APM just gives up at that point, rather than requesting the NEXT icon.

 

 

I've also noticed that when it does work with the work-around in place on the XMLBroker, the icon display is pretty slow... The remote desktop comes up first with generic icons. Then the icons are gradually refreshed one by one. At about 3-4 icons per second. On a desktop with about 50 icons, that can get annoying (Especially with users... They want the world :)

 

 

H

Looking deeper into the slowness of the icon updates... Firebug shows an 8 second login time (That could be the XMLBroker, it's pointing at a single test server until the admins can do the registry workaround on the production servers) followed by the icons being requested one by one... Trouble is, they're all requested using POST... Which isn't going to be cached... (And cache-control explicitly says no-cache!)

 

 

So why are the icons pulled using POST? (I'm running through the .js now to try & find the offending code and see if it can use a GET and take advantage of caching. Although I suspect the over-use of the same URI for every request is going to kill that)

 

 

H

Sigh... Refreshing the page also pops up the login requester...