Breaking Citrix XenApp Client side rendering


Breaking Flash client side rendering

Working on several projects at once you encounter many different issues that are interesting to investigate. Some of those issues however seem to be unknown to Citrix so far. The issue I’m describing below is one of those, when “googling” you find only a few hints towards the same issue and I think two posts in the fora about this with no solution what so ever.

First let’s clarify what is the case;

Client side flash rendering is a good thing and something that helps improve the users experience, no doubt about that. When however you have a site that doesn’t work properly with client side rendering you want to render that specific one on the server.

Citrix has also seen that and added a policy “Flash URL Compatibility list” to the Citrix policies. This policy allows you to add URL with or without wildcards to exclude those site from being rendered the default way.

Now when you have client side rendering active and you dare to add one URL in that “Flash URL Compatibility list” and make it active, client side rendering stops working.

 

So what’s the environment we looked at?

  • Windows 2008 R2
  • Citrix XenApp 6.5
  • Citrix Receiver 3.2
  • Internet Explorer 9.0.8112.16421 (Update 9.06)
  • Citrix HDX Mediastrwam for Flash – Server  version 2.0.1.0

If you look at the picture above you notice both the ActvieX and the plugin are installed. Keep that in mind….

What have we done so far to test this?

Policy:

A user policy that adds exclusions for certain sites, is added to the farm and filtered based on a few users just to see it’s behavior. The site that is added is http://producten.hema.nl (this is just a example, the customer site was added but I’ve changed that over here). The site itself is not of any importance, the policy behavior is the case.

We’re running IE9 and yes I know you need to add some register settings to make it work. Been there, done that.

IE9 fix:

For a 64-bit operating system

HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixHdxMediaStreamForFlashServerPseudoServer

Added the entry: IEBrowserMaximumMajorVersion / DWORD value = 00000009.

 

What kind of behavior do you see and how do you know client side is broken?

When you browse to the site entered in the list, server side rendering of the site is active. (you can disable the question about optimization as we did)

When you open another TAB in the same browser and e.g. browse to youtube.nl (Big Buck Bunny 1080HD) you will notice this also is rendered on the server.

Even if you open a new IE instance everything is rendered at the server, client side rendering is disabled for some reason.

HDX monitor

When you check the log files with HDX monitor it has several entries like this.

The site URL cannot be obtained from the browser to check against the dynamic blacklist

 

How can you see that client side rendering is not running on the client?

On the client the process PseudoContainer2.exe is never active when this URL compatibility policy is active. You can check this by opening the taskmanager and search for the proces, it’s not there.

Is there a workaround?

Yes there is, disabling the URL compatibility or having an empty URL list is a workaround to get client side rendering working. This however will have all sites client side rendered. So basically there is no workaround.

Is this a bug?

I looks like a bug, acts like a bug and feels like a bug, but perhaps I’ve done something incredible stupid and it’s not a but. At the moment it certainly looks like a bug.

hope someone tells me that I’m wrong and what I should do to fix it, untill then we’re in the dark waiting for a Citrix fix.

 

Update:

@BramWolfs did a check up for me and added http;//youtube.com/* to the URL compatibility list. Youtube therefore was rendered server side. Other sites he opened were still rendered client side. Asked him to check his Flash version etc  because perhaps that’s a difference we need to look at.

It looks so far that the difference is found in whether or not you have the plugin and the activeX or jus the activeX installed.

We have a demo R&D environment called Virtuall where we run demo’s for customers and do some R&D work for ourselfs. We tested the issue there also but couldn’t reproduce it. Looking at the server and the installed software one difference was spotted straight away confirming what Bram had tweeted already and does as I’m typing.

He and we in virtuall have only the ActiveX installed, no plugin. The proof is in the pudding, so here’s the picture

Now the only thing to do is see how we can change things so that we break it… I think it’s to simple to assume adding the plugin will break it.

Will keep you posted.

 

Update 26-06-2012:

A few days ago we received a private hotfix for this issue after Citrix was able to experience the issue internally also.

the hotfix included two DLL. PseudoServerinProc1.dll and PseudoServerInProc2.dll which we installed on a test server.

The fix has been installed on a test server and indeed did solve the issue.

However with this solving of the issue one other issue was introduced, Internet Explorer is less stable after this private hotfix. serveral users testing this hotfix have reported IE to crash.

Hopefully Citrix can find why this is happening and solve it…

Again I’ll keep you posted.

 

Hotfix available

For XenApp a hotfix is released… http://support.citrix.com/article/CTX134011

 

 


Leave a Reply

https://tracking.cirrusinsight.com/869c29e2-3a9b-48c5-9232-0b95e7993ae8/controlup-com-pixel-php