XenApp

About the XenApp 6.5 Group Policy Client Side Extensions (CSE)

2016-08-02
/ /
in Blog
/

TLDR; using a newer Citrix Group Policy Management (GPM) than 1.7.X on XenApp 6.5 will cause your policies to disappear if you upgrade your Client Side Extensions to a version higher than 1.7.6.

The Citrix Client Side Extension (CSE) are the ‘Citrix Group Policy Engine’.  The CSE takes whatever policies you set through Active Directory, locally or the AppCenter console and apply them to your server or Citrix session (if a user policy).  There is some oddity with the CSE and ‘Citrix Group Policy Management’ portions of the Citrix products.  You see, they are interoperable, but in certain scenario’s they are not.

The split appears to be for the XenApp 6.5 product for CSE 1.7.6+.  My Citrix TRM informed me that the Active Directory Group Policy Schema changed for CSE 1.7.6+.  If you intend to use CSE 1.7.6+ you will need to upgrade your Group Policy Mangement (GPM) to 1.7.11.  To upgrade your AD policy seems simple enough.  Citrix says open the policy on a computer with GPM 1.7.11 and then close it and it will become updated.

But here’s a bit of the rub.  Citrix supports and encourages “some” mixing and matching of some components.  Specifically, the Citrix Universal Print Server (UPS) and Client (UPC).

And here’s my story:

We wanted to use the 7.6 version of UPS/UPC as it had some improvements we deemed critical.  We had not upgraded the version of the Citrix GPM/CSE from what came with the Citrix XenApp 6.5 (1.5.0).  When we downloaded UPS/UPC 7.6 we found we could not configure the Group Policy  settings for the Universal Print Client… Until we upgraded the GPM that came with XenApp 7.6.  Then the UPM policies appeared, ready to configure.  The version of GPM included with XA7.6 was 2.2.0.

Only on reboot, with the policies set, we found they were still not applying.  At this time, I found you need version 1.7.0 of the CSE to recognize the new policies.  We installed CSE 1.7.0 and it recognized all the policies and we were flying.

Fast forward a year or so later and we decided to ‘get up to date’ with our operational software.  Essentially, we wanted to ensure we had all the bug fixes enhancements of all of the latest and greatest for XA6.5 so we can survive for the next couple years while we transition to whatever Citrix will have out by then.  So the latest and greatest CSE is 1.7.6+ and I installed it, and all my policies went poof.  This prompted my earlier post.

During the course of troubleshooting my issue I installed various versions of the CSE’s and GPM’s that came with the various versions of Citrix XenApp.  Since we had GPM 2.2.0 installed, nothing from the 1.7.6 CSE branch recognized any of the policies.  BUT, installing any of the CSE’s from XA7.5+ recognized and applied the 6.5 policies and everything on top of that.  So I started asking our Citrix TRM if it was supported to have the CSE from the newer XenApp 7+ on 6.5 and if they included all the policies.  The answer was ‘Maybe it works, probably not supported’.  So I asked why the policies of 2.2.0+ don’t work with CSE 1.7.6 and the answer I got was the schema changed for the GPO’s.  This is implied in CTX202233:

Note: This fix addresses the issue for AD policies you create after installing this update. It also addresses it for existing policies where Citrix settings were configured before Microsoft settings. It does not address it for existing AD policies where Microsoft settings were configured before Citrix settings. For those AD policies, you must open the affected policies and save the Citrix settings.

Opening and saving the policies updates the schema.

 

Read More

Citrix XenApp – Graphical Artifacts

2016-07-22
/ /
in Blog
/

In our Citrix XenApp 6.5 environment we started having a couple applications encounter an issue where they would experience some serious graphical artifacts.  What was supposed to look like this:

1

Would look like this:

2

 

Here’s a short video demonstrating this issue:

Or sometimes it would show the windows *behind* the artifacted image.  That is, instead of the ‘White’ you see in my image, the application behind it shows through.

When investigating this we found there was a couple symptoms that we were going to experience these artifacts.

  1. The window would become ‘frosted’ or ‘ghosted’ (as seen in Spy++ or AutoIt Window Info)
    4
  2. The application would switch to ‘Not Responding’
    3
  3. If you completed the task ‘Edit’ quickly there would be no artifacting (time was important)
  4. When ‘timing’ the switch from ‘normal’ to frosted or ghosted window it would be around 5-7 seconds.

So what’s going on here?

For this particular instance, the application is launching MSPaint with some modified properties.  It sets Paint to ‘Always On Top’, which in itself isn’t an issue, but then it purposefully locks the UI so you must complete the drawing and close paint before continuing.  This is how the vendor designed this application to operate with this workflow.

And what’s Windows doing?  It turns out, Windows is trying to alert you that your program is non-responsive!  Windows has a built in feature to ‘Frost/Ghost’ the window of a non-responsive UI to prevent you from entering input that won’t be received.  The ghosting effect is time sensitive!  So that explains why if we opened and closed our document quickly their would be no artifacting but if we manipulated it for some time the artifacts would appear.  The time limit for monitoring unresponsiveness is 5 seconds.  DWM.exe is the process responsible for creating the ‘Frost’ window and when responsive returns, it appears it does a poor job telling the application to repaint all affected Windows.

Microsoft recommends a couple ‘fixes’ which is really a programmatic way to ‘disable’ the ghosting feature.  The two methods Microsoft suggests is to create a NoGhost application compatibility fix or have the programmer use ‘DisableProcessWindowsGhosting’.  But there is a 3rd method.

The 5 second time limit is programmable.  If we extend the timeout we don’t need to configure ‘NoGhost’ compatibility fixes for each app or go back to the vendor.  The timer is global and affects every application and window.  Unfortunately, I know of no way to permanently disable it, but we can set a high enough value to prevent it from appearing.

So what do we have to do to ‘resolve’ this?

My preferred choice was to use Group Policy Preferences (Registry) and set a new value for HKCU\Control Panel\Desktop /v HungAppTimeout /t REG_SZ /d 120000

This sets the timeout to 2 minutes as opposed to 5 seconds.  Now when our program is used we get this result:

No More Artifacts.

When I was investigating this I found I could get the artifacting to occur in both ICA and RDP but not when on the console.  The frustrating thing about this issue is that it was not consistent.  Because of the 5 second default time limit, the program(s) we had that would ‘artifact’ would sometimes complete their UI locking job faster than 5 seconds, but sometimes not.  This lead to reports of artifacting occurring more often ‘during the peak work hours’ when the application/server/user load was the most.  This makes sense as the higher load undoubtedly lead to everything being slower, the database, server, etc. leading to the application waiting longer and thus exceeding the timeout.  I did find through the course of troubleshooting this issue that it seemed to ‘go away’ when I was trying to replicate after hours, which is frustrating to only have a slice of time to try and resolve this during peak hours.

Fortunately, after implementing the HungAppTimeout registry key the artifacts for several application ‘went away’.

Lastly, contrary to this article you do NOT need to restart for this value to take effect.  WinLogon.exe reads the HungAppTimeout value and then configures DWM accordingly when your profile loads.  So for this value to take effect you only need to log on with this value already residing in your user’s registry hive.

5

Read More

Citrix Client Side Extensions 1.7.6+ breaks policies

2016-07-14
/ /
in Blog
/

We apply our several group policy settings via Active Directory group policy objects, within them we set ‘Citrix’ policies.  This includes things like ‘Licensing’, platform, etc.

AD_Policies

 

When we upgraded the Citrix Group Policy Client Side Extensions (x86) to version 1.7.6 or 1.7.7 we found that these values were no longer being applied.  FYI!

 

 

Read More

Citrix XenApp 6.5 – IMA errors galore, mfcom won’t start

2016-07-04
/ /
in Blog
/

I’ve seen this happen a few times now where the “Citrix Independent Management Architecture” (aka IMAService) won’t start, erroring with various errors:

All of these errors appear to be a registry with incorrect permissions configured on the Citrix keys.  Why did these keys get their permissions reset?  I’m unsure.  I DID just install Citrix UPM 5.4 which may reset the keys?

Here is how you fix the permissions (at least, everything I could possibly find):
1) Download SetACL.exe
2) Save this file to ‘CitrixRegPerms.txt’:

You may need to identify the local SID for ‘NETWORKSERVICE’.  In my example the value is:

 

You may need to replace your SID for NetworkService with the one from my file above.

Lastly this script will ‘fix’ the incorrect permissions:

Done.

 

Read More

Multi-homed server, lock ICA and RDP to a specific NIC

2016-04-21
/ /
in Blog
/

We implement a multi-homed setup with Citrix Provisioning Services.  We have all of our production traffic on one NIC and all PVS traffic on a second nic.  This helps us in troubleshooting when doing packet captures but does introduce other sets of challenges.  One of these challenges is when I uninstalled and then installed updated VMWare tools on one of our vDisks it caused the NIC’s to renumber and reorder themselves.  You’ve probably read some articles saying to ‘show hidden devices’ and uninstall any ‘ghost’ devices; with a multi-homed setup this may not resolve your issue.  My specific issue is my NIC’s now went from “0x1 and 0x2” to “0x3 and 0x4” in the LANATABLE.  We apply a GPO to the ICA-TCP and RDP-TCP to force them to only utilize our ‘Production’ NIC which we decided was going to be the second NIC.

Provision = 1st Nic, Production = 2nd Nic

I uninstalled the ghost devices but because this change is all ‘in the registry’ it wasn’t immediately noticeable by myself that the LANATABLE and NIC ordering had changed.  I promoted my vDisk and then tried to RDP into it:

Well…  I knew this wasn’t right.  So I logged onto the server and checked the LANATABLE values:

Provision NIC
Production NIC

 

Provision NIC LanaID = 0x3 after the VMWare Tools upgrade

 

Production NIC LanaID = 0x4 after the VMWare Tools upgrade

 

RDP targets LanAdapter 0x1 (!?)

 

ICA targets LanAdapter 0x2

A couple issues popped out.   The first was that the LanaID’s were wrong.  I *thought* Provision should be #1 and Production should be #2, but we apply our LanAdapter ID’s via GPP so these values are correct for our other systems.  I know both RDP and ICA need to be locked to the Production NIC and the order is *correct* but I’m a bit confused to why the numbers are different between RDP-TCP and ICA-TCP.

So I started on getting the issues resolved.  First, I was going to resolve RDP.  If it is targeting 0x1 that means that I need the Production NIC (VMWare Network Adapter #2) needs to be set as 0x1.  So I edit the LanaId of the Production NIC to 0x1 and the Provision NIC to 0x2.  I rebooted the box and I could RDP into it without issue.  I then checked the Remote Desktop Session Host Configuration:

This is the correct value.

OK, so RDP is set correctly and works.  I then tried to launch a Citrix application.

It failed.

It generated an event on the server:

Unable to connect to the CGP tunnel destination

Looking at the ICA Listener configuration showed me the following:

The value is wrong.  It should be #2

So the ICA-TCP listener was set to the ‘Provision’ NIC.  So our production traffic was not getting to it. This is the wrong value.  My first thought was the LANATABLE would make sense here…  We have the LANADAPTER key is set to 0x2 which would equal the ‘Provision’ NIC under this configuraiton…   So I changed the LANATABLE to be the reverse.  0x1 = Provision NIC and 0x2 = Production NIC.

The results:

Now both are wrong!

Jeez.
I reverted the LANATABLE to 0x1 = Production and 0x2 = Provision.  Again, only the RDP-TCP connection changed.  At this point the ICA Listener *must* be looking at another place…  I used Procmon to trace the registry when I opened the ICA Listener Configuration and noticed it did NOT query LANATABLE but did go through and look and query this key:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesTcpipLinkage
The BIND order is set as Production (#2 NIC) first and Provision second in this order…  To change this order you need to go to Advanced Settings and modify the connection order:
Provision *should* be the top NIC here…
So I used the arrows on the side and moved Production to be second in this order:
Rebooted and I checked the ICA Listener:
Hurray!
I then tried both RDP and ICA traffic and both now worked correctly.
So, the lesson learned here is that this registry key:
Targets the BINDING order of the NIC’s.
And this registry key:

Targets the LANATABLE and the values specified within.

Read More

Citrix Director 7.7 & XenApp 6.5

2016-01-15
/ / /

Citrix has ‘replaced’ Edgesight with a new tool called Citrix DesktopDirector. It’s a monitoring tool that provides help desk or other type of technicians with data on what’s going on in user sessions (when referring to XenApp). Although vastly inferior to ControlUp, it is free.

But it’s not without poor documentation and its own tales of woe. We have Citrix DesktopDirector 2.1 currently live in our environment. Our environment is purely XenApp 6.5 (at the moment).

For version 2.1, logins are incredibly slow. Enumerating any sort of information on DesktopDirector is horribly slow. It’s just incredi-bad.

Enter Citrix Director 7.6 7.7; lots of promises to overcome the failings of the previous version.

First, installing Citrix Director 7.7 for XenApp 6.5:

1) Launch the AutoRun (AutoSelect.exe) installation file

2)
Select ‘Start’ for XenApp

3)
Select ‘Citrix Director

4)
Agree to the licensing agreement and click ‘Next

5)
Select ‘Next

6)
Without entering any information, select ‘Next

7)
Select ‘Next

8)
Select ‘Next’ for the firewall rules

9)
Select ‘Install

10)
Wait for the install to complete

11)
Open IIS Manager on the Director Server. Select the Director site under Default Web Site and double-click on ‘Application Settings

12)
Under ‘Actions’ click ‘Add

13)
For ‘Name’ enter ‘Service.AutoDiscoveryAddressesXA’ and for value put the IP of the local ZDC server

14)
If you are not setting up certificates on the server for SSL, you can disable the SSL verification by changing the UI.EnableSslCheck to false.

15) Reset IIS from the command line.

16)
On EACH XenApp server, install the Director WMI Provider (DirectorWMIProvider_x64.msi for 64bit OS’s and DirectorWMIProvider_x86.msi for 32bit OS’s). No reboot is needed, it takes effect immediately.

17) Enable WinRM on each XenApp server. In a command prompt run:
‘winrm qc’

18) Configure WinRM with the appropriate permissions:
ConfigRemoteMgmt.exe /configwinrmuser HEALTHYDesktopDirector.TST /all

**A NOTE ABOUT CONFIGREMOTEMGMT.EXE**

Ensure you use the latest version you can find. For XenApp/XenDesktop 7.7 the version that comes with it is:

It has been revised as time has gone on and numerous bug fixes have been implemented. We implemented a script to update our WinRM so all of our XenApp servers would have the user configured. We didn’t include checking, we just assumed if a group was added it would not be added again. With an older version of ConfigRemoteMgmt.exe this was an incorrect assumption and our WinRM SDDL became so large that the command line that ConfigRemoteMgmt.exe generates for winrm.cmd breaks the command line. You see, ConfigRemoteMgmt.exe is also a front end to “C:\Windows\system32\winrm.cmd“. Here is the command it generates:

C:\Windows\system32\cmd.exe /c “”C:\Windows\system32\winrm.cmd” set winrm/config/service @{RootSDDL=”O:NSG:BAD:P(A;;GA;;;S-1-5-21-38857442-2693285798-3636612711-99999999)(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)”}”

The part I bolded is the GUID of the object you pass in the /configwinrmuser. The ConfigRemoteMgmt.exe takes your object and converts it to a GUID and then sets the SDDL using the native Windows tools. The bug in a pervious version of this tool is that it would add another GUID, even if one already existed. So in the buggy version the next command would be this:

And so on. Eventually, this causes WinRM to fail and it will just hang at this point:

To check your WinRM Root SDDL, execute this command:

If you have an output similar to this, then you have a problem:

Fortunately, it’s a super easy fix. If you run the command with a single GUID it all gets reset:

And now you can execute the ConfigRemoteMgmt.exe command again. The new version of ConfigRemoteMgmt.exe doesn’t seem to just ‘stack’ the new version on top.

/**A NOTE ABOUT CONFIGREMOTEMGMT.EXE**

Now that you have WinRM configured, Director installed, you login and it works. So you try with a HelpDesk account and it fails:

In order to trouble shoot this, we need to turn logging on for Director. To do so, go into IIS Manager Console, to the ‘Director‘ Site, and double click on Application Settings. Turn on the following “Log.” settings:

Now, create the folder you specified the log will be captured in and set the following permissions on it:

Note: The permissions are %COMPUTERNAME%IIS_USERS

Restart IIS and attempt to login again. You should get a log file generated with content. A failed login had this output:

And a succesful login had this output:

I highlighted the lines in the successful output that showed the command succeeding and the output from that. So why did this fail? The one account “adtest91” is setup as a ‘help desk’ style account and has ‘custom permissions’; essentially ‘View-only’ but with some categories removed altogether. Could this be permissions based? The odd thing is DesktopDirector 2.1 works without issue with this exact same configuration.

Fortunately, Citrix tries to make this easy to troubleshoot. I will login to the ZDC and start a Citrix PowerShell session with “adtest91” and run the command it supposedly fails on:

Well, at least it appears consistent. So, apparently, we need to get this command working. My first try at troubleshooting was to login to the AppCenter console, go to Administrators and get properties on this account, and change it’s ‘Privileges’ from Custom to Full:

When I attempted to login it worked! So it’s definitely a permission issue. I went back to Powershell and executed the same command:

Success!

So if the Powershell command specified in the log file works then ‘Director’ should work, and so far that is what it looks like. Now I wanted to narrow down *which* permission does this as we do not want our Help Desk to have full control over the farm. The, very obvious, first thing that stood out was:

Edit Zone Settings.” We are having issues enumerating Zones, perhaps this setting enables you to *read* zones? I enabled this setting and retested:

Success! And our ‘Help Desk’ account can now login to Director.

We don’t really want Help Desk to have the ability to ‘Edit’ Zones but I don’t see a ‘Read-only’ permission so we may have to live with it.

So now we’ve logged into Director and we enumerate an account but we get this message:

Cannot retrieve the data. Cannot find the referenced object. View Director server event logs for further information.

The IIS logging shows:

And the event log shows:

The requested data could not be found in the data ‘The virtual desktop via WinRM service reported an exception. See the event log for more information.’ (‘http://WSCTXZDC301T.healthy.bewell.ca:5985/wsman’).

User: ‘HEALTHYadtest91’

Console operation: ‘Retrieving running application details for IMA Session…’

Additional information:

‘Exception of type ‘Citrix.Dmc.Common.NotFoundException’ was thrown.’

When I got this message with my ‘Administrator’ account I installed the Director WMI Provider and it started working. But with this ‘limited’ user account I was getting an this error. Amazingly, this error goes away as soon as a user logs in to Citrix Director webpage, who would also be a local administrator on the Director server. After searching and searching and troubleshooting and scanning and trying various things to get this working, the only thing that would work was to grant our Director group admin privileges on the Director web server. I finally stumbled across another article that reaffirmed that the only solution is to have the users be local admins on the web server.

https://support.software.dell.com/kb/154066

To test WinRM the following command can be used:

winrm get winrm/config -r:%server%      — Non-administrator user gets access is denied making WinRM queries

This error, though, is only if you set Connector.WinRM.Identity as ‘User’ and those users are not Administrators.  The fix, is to put your users into a group and make them a local admin on the Director server.

Read More

Help! My Citrix application is running slow (Meditech, Citrix, Imprivata)

2015-12-19
/ / /

We have an application (Meditech) that users have reported as performing poorly in Citrix.  They were able to confirm the poor performance by comparing it to a desktop that had the same software installed.  I was brought on to try and understand these performance differences and why Citrix would be performing so much worse.  To measure the performance, the user took me to a screen where they held down a key on the keyboard to increment a counter in the software.  When holding the key down on the desktop the counter was quick and incremented at a steady pace, on Citrix it seemed OK at first but then slowed as time went on.   To illustrate these performance differences, I made a video:

So we definitely have a problem.  My first steps on troubleshooting this problem was to compare the differences between the desktop and the VM.  The VM had server processors but they were older, and at less GHz at 2.6GHz for the server.  The desktop had 3.4GHz processors with a newer generation.  If the processing is NOT latent sensitive then the faster processor’s can make a difference, and the CPUMark had them at 1500 and 2100 (~40% difference).  At first glance, this seems like it could be the difference in our timings but it’s still too drastic at ~5s vs ~20s, a 400% difference.  To try and narrow the difference I took the application to a completely bare server with no software on it what-so-ever and reran the test.  It completed in about ~5-6s.  The processor it ran on was comparable to the original server processor but ran at 2.7GHz instead.  The processor was not running at nearly enough speed to make up the difference, something else must be consuming those cycles.

At this point I procmon’ed the benchmark and came up with the following:

(PID 6660 is the process that the benchmark runs against)

Very obviously, the pattern of each key stroke on the Citrix server is present with the initial pattern highlighted:

About 400ms from each key stroke to when the next one is registered.  So what is delaying the 400ms?  From my experience, unexplained delays are CPU related.  I then looked at the process activity summary to see if I can find the bottleneck:

Again, very obviously we are seeing the CPU ramp up, and it can also explain the faster, initial iterations of the GUI as the CPU ‘ramps’ up and doesn’t spike to the it’s maximum.  None of the other graphs show any activity at the time of the benchmark so the suspect is highly on the CPU.  When hovering over the graph we see the CPU percentage.

This is a 4 core box, so ~25% equals one full core for a single threaded application.  Again, this points to the application being bottlenecked by the processor, but again, the difference is too large to consider just the CPU at this point.  We need to find what part of the process is consuming these resources.  Fortunately, ProcExp (process explorer) can help us determine what is going on within a process.

I started a new run and got properties of the process:

MGUI.DLL is consuming all of the CPU.  That is a DLL utilized by the application, clicking on ‘Stack’ gives us the hierarchy of commands being utilized by that thread.

From this, I can understand that ntoskrnl.exe, ntdll.dll are native Microsoft Windows functions, MGUI.DLL is utilized by Meditech, but what is ISXHook.dll?

Doing a search within the process shows that it’s utilized by Imprivata, a single sign-on solution we utilize to try and increase user efficiency.  It works by ‘screen scraping’ to determine fields that it needs to populate with user credentials to try and speed up user logins.  Logically, this sounds like it could be causing the delay by screen scraping every time a key is stroked or a change is registered.  To confirm this, we need to remove Imprivata from the application.  Fortunately, it’s hooked in by services that can easily be terminated.

I’m going to terminate everything that says ‘Imprivata Inc.’

With the processes terminated I reran my test.  Using Process Explorer and getting properties on the process, immediately CPU usage went from 25% down to 15% at a peak:

And getting Stack information showed a much cleaner stack:

In conclusion, I may need to investigate into Imprivata to determine if I can reduce its polling rate or find some way of allowing it to ‘stop’ polling the CSMagic process *after* the accelerated login.  Its current settings (which I’m not familiar with, sadly) is not acceptable and causes a significant slow down.  Fortunately, the root cause has been determined and we can work towards a full resolution.

Read More

Performance differences in Citrix HDX Thinwire Encoders

2015-09-04
/ / /

Per my previous post, changing the Citrix HDX Thinwire Encoder on the fly, we can test the performance differences in the different encoder’s Citrix provides.  I have done so by running through a demo of the Uniengine Heaven benchmark.  The demo is exactly 4 minutes and 20 seconds long.  I did a perfmon trace of the CPU %, total bytes sent in MBits/sec and the Thinwire Output in MBit/sec.

Time for some results!

Compatibility Mode (Encoder 0x0)

DeepCompressionV2Encoder (Encoder 0x1)

DeepCompressionEncoder (Encoder 0x2)
(Rollover the mouse on the next images to compare graphs)

CompatibilityMode vs DeepCompressionV2Encoder

CompatibilityMode vs DeepCompressionEncoder

DeepCompressionV2Encoder vs DeepCompressionEncoder

The cumulative totals should help us get an understanding of the differences between the encoders:

   CPU Total ThinWire Total Network Total (Mbytes)
DeepCompressionEncoder 5531.00 3693.28 540.51
DeepCompressionV2Encoder 5621.67 3684.75 539.74
CompatibilityMode 4197.54 3690.58 553.21
   CPU Total ThinWire Total Network Total (Mbytes)
DeepCompressionEncoder 98.4% 100.0% 97.7%
DeepCompressionV2Encoder 100.0% 99.8% 97.6%
CompatibilityMode 74.7% 99.9% 100.0%
Interestingly, CompatibilityMode uses 25% less CPU then either DeepCompression Encoder.  From what I see though the frames per second appears less for CompatibilityMode then the other two.
Read More

Change Citrix HDX Encoder on the fly for testing

2015-09-04
/ / /

Rachel Berry posted an article on optimizing HDX for gaming.  In this article she highlighted that Citrix has some ‘special’ registry keys for modifying different parameters of the Thinwire encoder.  One of these keys was changing the encoder itself:

  • Encoder = 2 is Pure H.264 (YUV 4:2:0). As with most vendors this is H.264 4:2:0 format, it’s designed for a balance of quality and bandwidth primarily on video and high-bandwidth CAD parts (not much text). This is used by the HDX 3D Pro VDA.
  • Encoder = 1 is H.264+lossless text. This is used by default by the XenDesktop standard VDA and XenApp VDA.
  • Encoder = 0 forces you to use Compatibility mode

In terms used by HDX, it shakes out like so:

Encoder 2 = DeepCompressionEncoder
Encoder 1 = DeepCompressionV2Encoder
Encoder 0 = CompatibilityEncoder

The cool thing about these encoders is you can modify their values *on the fly* and it will take place immediately in your Citrix session. This video I made demonstrates this. I ran a 3D benchmark application and modified the encoder’s on the fly. I zoomed into the FPS counter and put this in the bottom left corner as the text with moving images shows much better the difference in the encoders.  Without a doubt, the CompatibilityEncoder has the worst quality of all the encoders when it comes to video/moving images/3D/gaming.

Try to watch it in 1080p for maximum quality.

To change the encoder, you need to add/modify a registry key at HKLM\Software\Citrix\Graphics.  The type is DWORD32 named “Encoder” and the value is 0x0 to 0x2, depending on the encoder you want to try and use.
All testing was done with XenApp 7.6 on my home built lab.
Read More