Wednesday, February 13, 2013

Citrix Online Plugin 14

Hi All

One of my more popular posts discusses the ability to extract Citrix Online Plugin 13 from Citrix Receiver 3.2.  Whilst doing some testing with Receiver 3.3 it was apparent that Citrix have included Citrix Online Plugin 14 with 3.3 onwards.

Support Information from Receiver 3.3
<?xml version="1.0" encoding="UTF-8"?>
<Diagnostic version="1.0">
  <Receiver version="">
      <Name>Self-service Plug-in</Name>
      <Name>Online Plug-in</Name>
      <Name>Online Plug-in</Name>
    <Errors />

Remember, PNA has been removed from the standard Receiver download, you need to get a different version first.  This is discussed in a different blogpost which is below.

Once you have downloaded the correct Receiver executable you can just install the Online Plugin as before.

or if you just want the code, here it is

CitrixReceiverEnterprise.exe ADDLOCAL="ICA_Client,SSON,USB,DesktopViewer,Flash,PN_Agent,Vd3d" ENABLE_SSON="Yes"

I have sinced realised that Online Plugin 14 actually comes as part of Project Excalibur.  This is the project to fuse XenApp and XenDesktop together.  I can't see any notable differences but it is fair to say I haven't tested it thoroughly.



Friday, February 08, 2013

IE9 hang......with no window?

Hi there

Recently we have had an issue with our published XenApp 6 desktop platform not performing very well.  We looked into the normal metrics and we saw the CPU usage on particular servers could be high.

Initially we checked the process list and saw that iexplore.exe for one user would usually be the hungry process, taking lots of CPU.  This was originally associated with someone browsing to a site they shouldn't have.  The DFSS service which is on by default for Windows 2008 R2 RDS servers stopped this being a tragedy as other processes recevied CPU time when required, but there is only so far DFSS can go.

Some information on DFSS

On further inspection (actually calling the user to understand their experience) it was clear that no process window was open at all and that the iexplore.exe process had simply hung.  Ending the process had no effect on the user whatsoever.  Some of the users mentioned that IE had become unresponsive, but the window closed correctly.

Now this was difficult to track, I couldn't find a way to identify this hung process with RDS or XenApp.  I tried all the normal methods like ProcDump, WhatisHang, ProcessExplorer....but all of them didn't recognise the process was in a hung state.

Trying to reproduce the fault was very difficult, however not impossible.

Open 1st tab with
Open 2nd tab with the browser hang test from Microsoft

Click the button which says Click to Hang Temporarily

Click the red Close button in the top corner
Click button Close all tabs

What occurred in our environment was the iexplore.exe process remained after closing the window and would take lots of CPU processing.  Like this!

See iexplore.exe taking 20%.....but no IE9 window is open.

After some investigation I remebered that a group policy was created call Set Tab Proccess Growth.  The idea behind this registry key is to decrease the amount of processes loaded within an Internet Explorer window.  By default RDS sets this figure to 1, which means a new iexplore.exe process will open with every tab.  This is fine, it allows each tab to have it's own process.  If one of these hangs or crashes, the rest should be unaffected. 

The downside is the extra memory usage it creates e.g.  a 4 tab IE9 window uses 230MB, however if we change this value to 0 (1 iexplore.exe process for unlimited tabs) the memory usage is only about 170MB.  It doesn't sound a lot, but multiply that by 20 people and another 1GB of RAM is required on the server.

In our environment it was set to 0 to decrease the memory overhead.

Changing this value back to default (1) solves this issue in my repro environment.  We are testing this across the board but I am confident that this will solve the problem.

This setting can be change in Group Policy under

Computer configuration > Windows Components > Internet Explorer > Set tab process Growth (not configued or 1)

User configuration > Windows Components > Internet Explorer > Set tab process Growth (not configured or 1)

Or in registry by editing keys

HKCU\Software\Microsoft\Internet Explorer\Main\  DWORD value TabProcGrowth = 1
HKLM\Software\Microsoft\Internet Explorer\Main\ DWORD value TabProcGrowth = 1

More details on this feature can be found here.

My thought is that this feature does not play nicely with IE9 hang resistance feature at all.  I do not have definitive proof of this, but this GPO never had a problem with IE8 previously.  I suspect that as each tab shares the main iexplore.exe process, it cannot resist the hang as designed. 

Some more details on IE9 Hang Resistance below.