Citrix Display modes: How to configure, what to configure, when to configure

graphics

It’s been a while since I wrote my last blogpost, so I thought it was about time to write a follow up regarding Citrix graphics!

Lets get back in time first, my previous 2 blog posts about Citrix display modes are still very relevant and will give you a good overview about :

A while ago I started to write part 3 : How to configure, what to configure, when to configure. The main goal for this blog post was to give an understanding about all the display modes and related settings.  Lets start with summarizing the available Citrix display modes we know today :

  • Legacy Graphics mode (this includes the first Adaptive Display generation and the older progressive display technology)
  • Thinwire Graphics mode (this includes the new H.264 video codecs (Pure H.264 and H.264 Optimized for text) and Thinwire plus, the latter is also known as Compatibility mode)
  • Desktop Composition Redirection (combination of Thinwire graphics and Aero\DWM remoting to offload DirectX commands to the client)
  • Framehawk (new graphics mode which is based on predicting technologies to optimize graphics for high latency connections (UDP based))

So the initial goal of this blogpost was to help understanding all of the policies and settings related to above display modes. When a specific setting applies and when not, etc.
In the meantime my colleague Barry Schiffer was also busy with this subject and had the idea to give a presentation  together at E2EVC about the various display modes. Our goal was to give insight in the consumed resources of every display mode and help you decide which configuration would be the best fit for your environment. This is where the idea was born to develop  a tool to show valuable information about the current display mode while running your remote workload in the background. This tool would be targeted to admins and not users.

When it comes down to configuring display settings one size doesn’t fit all, so I decided to stop writing the part 3 blog post and instead build out the tool so you can experience every display mode and settings for yourself. I think this tool will make you understand the display modes and its behavior even better then only reading about it!

Remote Display Analyzer

So this is how the Remote Display Analyzer project has started. The main goal of Remote Display Analyzer is to make the display modes understandable by showing only applicable information for the detected display mode. It helps you decide which configuration fits best in your environment and will help you detect miss configured settings and resource bottlenecks.

Imagine to take place behind your old thin client (which for example can’t be replaced because of tight budgets) and detect at which display configuration the user experience is optimal and in balance with the resource allocation. Or to check at which settings your branch office performance best, or just to get a better understanding about the behavior of a given display mode. Sounds great right?

Over time the project evolved in much more then only showing you real-time information that matters, Remote Display Analyzer is also able to show you which settings you can change and change them on the fly!
This makes it possible to run your remote workload in the background and flip settings to get a deeper understanding of what is happening in real-time without having to logoff and configure different policies by yourself etc. Because the naming of the settings are the same as you find in the policies it’s easy to replicate the optimal settings in your production environment.

Change display settings on the fly

Besides live switching through settings, Remote Display Analyzer is also able to switch between display modes. For example you can live switch between Thinwire and Framehawk and from Thinwire to Desktop Composition Redirection(DCR) and vice versa when your client and VDA supports it.

Change display mode on the fly

Enough talking try it for yourself, hopefully you like it!

Availability

Remote Display Analyzer is available in 2 editions :

  • Lite edition, which gives you the ability to view display settings and real-time analytics
  • Sponsored edition, which provides all the functionality of Remote Display Analyzer like changing settings on the fly and advanced settings

Of course I hope to welcome you as sponsor of the project to even add more functionality in the future and to keep Remote Display Analyzer up to date. For more information about sponsoring and downloading Remote Display Analyzer please visit the website : www.rdanalyzer.com.

Thanks for reading!

A graphical deep dive into XenDesktop 7

Make sure to also check this blogpost about a very handy tool named Remote Display Analyzer

A graphical deep dive into XenDesktop 7graphics

Intro

A while ago I wrote an article about Adaptive Display and how it can be fine tuned. Well Adaptive Display as we know it hasn’t seen the light for a very long time because a lot has been changed in XenDesktop 7. In this blog post I will describe this changes and dig deeper in the configurable options related to graphics in XenDesktop 7.

Adaptive Display First generation = Legacy Graphics mode

In a short time frame a lot have changed in the delivery of graphics, users are demanding more media content, higher frame rates and a fluid user experience. While Progressive display did a very good job for a long time, it required a lot of manual tuning to accommodate different use cases, because of this it was often misconfigured resulting in a degraded user experience. To overcome this problem Citrix developed the first generation of Adaptive Display, it was still based on settings around progressive display but it was now auto tuning according to the available bandwidth and the capabilities of the client device. The concept of this first generation was simple : use a different compression algorithm for moving images and still images and tune it on the fly.

Adaptive Display Second generation, the new standard in XenDesktop 7

Well this concept is pretty much the same in the second generation of Adaptive Display but it’s now based on different codecs, the SuperCodec as Citrix calls it can dynamically decide which compression is used for different parts of the screen. The most important codec that is used in the second generation of Adaptive Display is the H.264 deep compression codec which we also know from HDX 3D Pro, together with features like Desktop Composition Redirection it forms the base of Adaptive Display second generation, before I go on let’s summarize the most important new graphics settings in XenDesktop 7 :

Policy

Default setting

Goal

Legacy Graphics Mode Off Revert to Adaptive Display first generation
Target Frame rate 30 Sets the maximum frames send to the client (now up to 60 FPs can be configured!)
Visual Quality Medium Sets the level of compression for the new codecs, besides low, medium and high also build to lossless or always lossless can be selected
Desktop Composition   Redirection Enabled Render Windows Desktop Manager (WDM) generated graphics on the client
Desktop Composition   Redirection Quality Medium Sets the default level of compression for Desktop Composition Redirection

I think the above settings are the most important changes in XenDesktop 7 according to graphics, besides that there are a lot of windows media related policies added. There is nothing really arranged what’s current and what’s legacy so it’s easy to get lost if you don’t know where Citrix came from with Adaptive Display first generation and beyond. You can only see on what kind of OS it applies but that’s about it.

I tried every combination of the above policies and made an UML diagram of my findings, the diagram shows the descisions made from the moment the session is launched (click to enlarge) :

Graphics UML XD7

H.264 Deep Compression codec

Citrix was the first vendor to use H.264 compression for delivering graphics through their remote display protocol (ICA), it was targeted for a specific use case : 3D modelling and graphics designers. At the beginning the first version of this codec was only available when combined with Nvidia GPU cards that had enough Cuda cores, as the codec was designed to leverage the Cuda cores for compression and encoding.

Later the codec have evolved and Citrix made it also possible to encode completely in CPU. The new version, called the Deep Compression V2 codec, uses even less bandwidth then it’s predecessor and since it’s CPU based it can be used for a lot more use cases. There is one downside though, since it’s CPU based (default setting) the load on the host side increases and can affect the scalability of the total solution, when CPU resources are limited or scalability is a concern in your environment you have the following options in XenDesktop 7 (please note that it’s about finding the right mix between server scalability, bandwidth usage and user experience. What’s best for your environment depends on the use case and of course the amount of $$$ you can spend) :

Option 1 : Leverage the new Desktop Composition Redirection feature to offload the host CPU

Citrix extended the aero redirection feature (known from 😄 5) and made it possible to remote Desktop Window Manager (DWM) DirectX commands to the client to be rendered there. This also means that graphics generated from application like Internet Explorer, Office 2010 and other modern applications are offloaded to the client. You will also notice when installing the XenDesktop 7 VDA on Windows 7 that the Aero theme is enabled by default, even when you disable Desktop Composition Redirection the Aero theme can still be used completely rendered on the new WDDM driver on the host side. The quality of Desktop Composition Redirection can be configured in the following policy :

Desktop_Composition_graphics_Quality

While this feature is awesome, since it leverages the clients capabilities and thus lowering the resources needed on the host side, there are some attention points when using Desktop Composition Redirection:

–          On the host side you need a Desktop OS (Windows 7 or Windows 8)
–          On the client side you need a compatible Windows client with a moderate GPU
–          Doesn’t work in legacy graphics mode (Adaptive Display first generation)
–          Increased bandwidth when using server rendered video

Desktop Composition redirection together with the new compression codecs forms the base of Adaptive Display second generation. It’s a combination that’s default enabled when connecting from a windows Client. If you use this combination you have to keep them both in mind when fine tuning the user experience. For example you configure the visual quality to always lossless to prevent lossy data send to the client (for medical purposes for example).  You will still see lossy artefacts like the below example in Wordpad.

Desktop Composition Redirection wordpad example

To get a really lossless experience you have to either disable Desktop Composition Redirection or set the graphics quality of Desktop Composition also to lossless, increased bandwidth consumption needs to be taken into account of course.

Option 2 : Turn on the legacy graphics mode policy

When you use the default graphics settings in XenDesktop 7 and you open HDX Monitor, you will see under Graphics – Thinwire that Adaptive Display is disabled (see below screenshot) and that thinwire redirection is disabled by a policy. This means that you are leveraging the new codecs and not using Adaptive Display first generation.Adaptive_Display_OFF

When you look at Graphics – Thinwire Advanced you will notice that the Legacy Graphics mode is turned off with the Legacy Graphics mode policy (see below screenshot).

ThinWire_Advanced__HDX_Monitor_PolicyOk so this is the default, now when user density and scalability is more important than the mobile user experience it’s possible to revert back to Adaptive Display first generation by enabling the Legacy graphics mode policy. Please note that you also have to switch off Desktop composition redirection to make this work. When you have done that you can verify that Adaptive Display first generation is back in business again through HDX monitor :

Adaptive_Display_ON_LegacyYou will also notice that, when using Windows 7, Aero functionality is switched off when using legacy mode:

Shutdown_button_legacy

For further fine tuning the legacy graphics mode in XenDesktop 7, read my previous blogpost on Adaptive Display.

Option 3 : Use Graphics Processing Units (GPU)

Instead of rendering and encoding everything in CPU, you can also leverage a GPU to do the heavy lifting, after all this is where a GPU is built for. Moving the graphical load away from the CPU, means you have more resources available for your applications etc making the solution more scalable. In XenDesktop 7 you have the following options :

–          Leverage the GPU directly (Either physically or through the Hypervisor (GPU passthrough))
–          Leverage the GPU indirectly through GPU virtualization (Available by using Nvidia GRID\VGX)

Leveraging the GPU directly is available for a while now but since it’s a one-to-one solution (except when using hosted shared desktops, where you can share a GPU with multiple sessions on the same server OS) it’s not very scalable and mostly limited to be used for heavy graphical designers and alike use cases. VGX on the other hand will extend the use cases by delivering a one-to-many solution. Personally I think this is the future because it provides the best combination of scalability, bandwidth and user experience. Let’s dig a bit deeper in VGX.

When we open HDX monitor in a XenDesktop 7 session you will see the below message when VGX is not available :

VGX_Frame_Buffer_Disabled_HDX_Monitor

Screen scraping vs Direct frame buffer access

When you have a GPU available graphics are first rendered on the GPU before they are (deeply) compressed in CPU and then send down the client, so first the output of the GPU (which would normally be send to the monitor attached to it) needs to be captured and after that compressed and tuned, this process is called screen scraping.

Screen scraping, while better than doing everything in CPU, consumes additional resources and this is where Nvidia VGX (formerly known as Monterey and now called NVIDIA GRID technology) comes to play, they provide an API which allows remote display protocols to access the frame buffer (the dedicated H.264 encoding engine of the GRID card) directly. The below picture shows how the GRID technology is integrated on the Hypervisor level :

VGX (Source Nvidia)

NVIDIA User Selectable Machines (USM) (Now called VGPU Profiles)

USM is the way Nvidia licenses the GRID technology, you can also translate the USM to use cases. There are 3 configurable USM’s :

Standard USM (bundled with the NVIDIA GRID card enabling a true PC experience for up to 100 task workers)
NVS USM (mission-critical professionals who use a variety of productivity and dedicated business applications)
Quadro USM (designers, artists, and scientists that require interactive 3D graphics and full compatibility)

So when you want to leverage the GRID virtualization technology you can do this for about 100 “normal” task users on a single GRID card (this can be less or more depending on the type of card and type of users), in this way you can already build a high scalable solution for general use cases. For more heavy graphical demands you need NVS USM or Quadro USM and this will cost additional licenses, good thing is you can mix and match the USM’s on a single GRID card. Of course the limits of the GRID card needs to be taken in to account. For more information about Nvidia GRID and the USM use cases click here.
XenServer will be the first hypervisor supporting GRID GPU virtualization, at this time of writing it’s not yet available but you can already order servers with GRID cards and leverage the onboard kepler GPU’s by using traditional GPU passthrough technology.

** Update **
1 October 2013, Citrix and NVIDIA released the GRID VGPU (Tech Preview) and made some changes in names and numbers :

– USM is now called VGPU Profiles, where K100 profile being the lowest which supports a maximum of 32 VGPU’s per board (K1 Card) and K260Q being the highest, which supports 4 Power Users (designers) on a K2 Card.
– In the following table you will find the maximum VPGU per card.

TP_Maximuns_VGPU

– Cannot find anything on licensing, it looks like the above hardware limits are the only limitation in the tech preview.

Conclusion

In this blogpost I described the new graphics options and choices you have in XenDesktop 7, remember that you don’t have to configure anything to get an awesome experience out of the box. The CPU based deep compression codec is really a giant leap forward compared to the first generation of Adaptive Display especially when it comes down to mobile user experience and WAN use cases. As more Citrix Receivers supports the new codecs it’s really a fluid experience across a broad range of devices. But keep in mind that you need additional resources on your host side compared to the “legacy display mode”.

Personally I had the best experience with the visual quaility set to Build to Lossless and disabling the desktop composition redirection feature, of course this depends on the use case, what I primary tested was server rendered video (youtube) and the look and feel of the desktop over a high speed WAN connection. What also amazed me was the look and feel of Windows 8 on the IPAD with receiver 5.8, they really made a big step forward making it a native mobile experience and playing video content really performed very well using the new codecs.

Can we safely say that Adaptive Display first generation and progressive display become absolete?
Yes I think so, but for now there is still a valid use case : for example, when you want to get high density numbers and you have primarily LAN users Adaptive Display first generation still gives you the most scalable solution, but as CPU’s become faster and when GPU’s with GRID technology become more mainstream (also for general use cases), I think we can say goodbye to the good old progressive display after all those years.

Please note that the information in this blog is provided as is without warranty of any kind, it is a mix of own research and information from the following sources :

Edocs (Optimize graphics and multimedia delivery in XD7)
Edocs (GPU acceleration for Windows Desktop OS)
– Blogs from Derek Thorslund (reinventing HDXHDX leaps ahead GPU sharing and Optimizations for W8\W2012)
– Nvidia (GRID Technology, GPU Virtualization)

XenDesktop 7, are XenApp Advanced customers left in the dark?

left in the darkI’m sure it didn’t escape you, but this week Citrix announced XenDesktop 7 (formally known as Excalibur), I think it’s awesome that XenApp and XenDesktop finally melt together as one, XenApp is not disappearing but it is just a simple VDA agent you install on top of RDS 2008R2 or 2012. What is disappearing is the whole IMA architecture, this is taken over by the FMA architecture known today in current releases of XenDesktop.

The 2 main editions of XenDesktop 7 are:

– XenDesktop 7 Platinum (lots of added value here)
– XenDesktop 7 Enterprise

Besides that there are 2 other editions :

– XenDesktop 7 VDI Edition (basic VDI functionality)
– NEW : XenDesktop 7 App edition (XenApp functionality only)

Citrix released a blog post regarding XenDesktop 7 and what it means for current XenApp customers, at the bottom you can find :

XenApp Enterprise and Platinum customers with active Subscription Advantage can update to this (XenDesktop app) edition at no additional charge and migrate their environments at their own pace.

So what can we conclude here and what does this mean for XenApp Advanced customers with Active Subscription?

1: This customers cannot upgrade to Windows 2012, as XenApp 6.5 is the last edition they can use and it’s only supported on 2008R2
2: This customers are stuck with IMA and cannot integrate it with the new FMA architecture of XenDesktop (think hybrid environments, with different license use cases)
3: This customers can upgrade their XenApp 6.5 environment with rollup pack 2, which is released at the same time as XenDesktop 7, while this brings a lot of the same functionality of XenDesktop 7 App edition to XenApp 6.5, will this be the case on ongoing basis?

This is what the main benefit of Citrix Subscription Advantage is according to Citrix :

Get free version upgrades:  download new version releases at no additional cost. These updates include any major changes to the underlying product architecture as well as updates to the feature set of a given product platform. (source)

As you can read, this includes any major changes to the underlying product architecture, can we translate the underlying architecture to Windows? or just the Citrix product? either way XenApp Advanced customers with an active subscription has disappeared from the radar since the XenDesktop 7 announcement.

Comments are already filling on their blogpost, so hopefully Citrix will provide more information about this later (UPDATE: see this article for more information), I think a decent trade-up (and not the existing trade up to the named license model) for this customers should be in place. So they can use it the same way as today (CCU), after all it’s not their choice that there will only be one edition of XenApp left (XenDesktop App edition), so it’s not really fair to left them behind in the dark while paying a fair amount of subscription fee to get the latest versions (Citrix) on the latest platform (Windows).

Please note that the information in this blog is provided as is without warranty of any kind.

A Deeper look into Workspace Control and its challenges

Table of contents :

1: Introduction
2: The Workspace Control process in UML
3: Workspace Control and Auto launch usability
4: Special note : Using Workspace Control with Receiver for Web
5: Special note : Using Workspace Control with Linux Receiver
6: Special note : Using Workspace Control with Native Receiver and Mobile Receivers
7: Conclusion

1: Introduction :

In this blog post I will dive a little deeper into the Citrix Workspace Control functionality, I will show you how the Workspace Control process works and what kind of challenges it can bring to the table. For those not familiar with Workspace Control, it’s the mechanism in Webinterface and Storefront that lets users (automatically) reconnect to existing sessions when they are roaming. To start with some basics : Workspace Control can reconnect two types of sessions, Active sessions and Disconnected sessions.

The Workspace Control process is triggered in the following 2 scenarios :

– The Automatic reconnect process when a user logs on to Webinterface or Storefront
– The Manual reconnect process when a user clicks on the reconnect button in Webinterface or Storefront

Workspace Control isn’t triggered in the following scenarios :

– When a user clicks on an application or desktop manually
– When Auto launch is enabled
– When you connect straight to a XenApp server, without using Webinterface or Storefront
– When Workspace Control is disabled, either by admin or user
– When points apply that you will find in the following UML flow diagram in the following chapter

2: The Workspace Control process in UML

Below you will find an UML diagram that will show you the Workspace Control process based on the Automatic and Manual reconnect process. (click to en large)

3: Workspace Control and Auto launch usability

Auto launch is a feature you can configure in Webinterface or Receiver for Web to launch a specific Application or Desktop after a user logs on, this functionality is especially useful when you have only one published desktop.  In this way the user doesn’t have to click the desktop icon, but instead it launches directly after the user authenticates. The downside of auto launch however is that it disables the Workspace Control functionality at logon. This isn’t necessarily a problem when using XenDesktop, but for XenApp this can result in multiple sessions being launched by the user and this is something you often want to prevent, it’s getting more worse when you have session limits in place because this can even prevent the user to login when there is already an active session. To overcome this I often use one of the below two methods, please leave a comment when you use other methods to solve this challenge for XenApp.

1: Restrict users to a single session, Enable Workspace Control and Disable Auto launch
In this scenario the user logs on to Webinterface or Storefront, when there is no active\disconnected session the user clicks on the Desktop or Application and launches his session. When the user logs on from another device, Workspace Control kicks in and reconnects the session immediately after the user authenticates. The user can also choose to manually disconnect and reconnect the session through Workspace Control. In this scenario Workspace Control in combination with Session limits is used to control the number of sessions on the XenApp farm.

2: Allow multiple sessions, Enable Auto launch and use RES session guard
If you have RES Workspace Manager in place, you can leverage the RES session guard feature to notify users of already active sessions and let them disconnect them on the fly. If you educate the user how to use this, session guard can be a real handy feature to simulate a Workspace Control alike functionality. Plus you can also define a group of users (through a dummy  administrative role) that can login multiple times. This is especially handy when you have shared accounts or a couple of users that needs to logon multiple times concurrently. The only down side of this method is that the user needs to login twice when an active session is detected, one time to disconnect the session and one time to reconnect to the disconnected session. The plus side is that you can enable Auto launch to immediately launch the Desktop after the user authenticates, because RES session guard will control the amount of sessions and you don’t have to use Workspace Control in combination with Session limits anymore.

Below is a printscreen of the RES Session guard in action when multiple sessions are detected :

Session Guard detects multiple sessions by creating a lock file (guard.lock) inside the homefolder , the above message is displayed when the file is detected, after the user logs off the lock file is removed.

4: Special note : Using Workspace Control with Receiver for Web

From Storefront version 1.2 the Auto launch feature is enabled by default in Receiver for Web when there is only one published Desktop available for the user, this also means that Workspace Control is disabled by default, but the most important thing to note is that since the separation of Apps and Desktops in Receiver for Web, the Workspace Control functionality is completely disabled in the Desktops section (see below screenshot for clarification). This makes sense when using XenDesktop, but you may still want to use Workspace control for your published XenApp desktops. To enable Workspace Control for published XenApp desktops, you can put a keyword in the published XenApp desktop description field (KEYWORDS:TreatAsApp) so Receiver for Web will treat it as Application instead of Desktop, thus enabling Workspace Control again.

Workspace Control (for the Apps section) can be configured by editing the web.config file in the inetpub directory of the Storefront server, this is a little step backwards because with Webinterface you could do this through the GUI.

5: Special note : Using Workspace Control with Linux Receiver

Linux Receivers found in linux based Thinclients often use the PNAgent site to request and launch published applications and desktops, the key component used here is the PNABrowse utility. PNABrowse is often scripted by the Thinclient manufacturer and embedded in the customized Thinclient OS, like the HP ThinPro and HP Smart Client series. PNABrowse uses the –WR parameter to leverage Workspace Control and connect to active and Disconnected sessions. You can control Workspace Control behavoir for this clients by editing this parameter in the following way :

-WR = Connect to Active and Disconnected sessions
-Wr = Connect to Disconnected sessions only
– Remove –WR = don’t use Workspace Control

There will be a new Linux Receiver released by the end of the year that can connect natively to Storefront without using Legacy PNAgent.

6: Special note : Using Workspace Control with Native Receiver and Mobile Receivers

For the Windows Native Receiver and Mobile Receivers connecting to Storefront, there is currently no good way to configure Workspace Control, it’s always enabled by default. Native Receivers are a good launch platform for published applications and data, but it lacks the option to fine tune them for different access scenarios like Workspace Control or Auto launch, you have to use the Receiver for Web or Webinterface if you want to control this. Also the native Receivers doesn’t make a difference between applications and desktops yet (only apps and data), so Workspace Control will be enabled for both by default which can be a problem. Hopefully Citrix will add more options to control this behavoir in future releases of Storefront.

7: Conclusion

The main goal of Workspace Control is to reconnect published applications when users are roaming, but it’s also often used in combination with session limits to control the number of user sessions and optimize the user experience. It’s clear that Citrix is moving away from Workspace Control when using published Desktops and rather use Auto launch instead, but for XenApp this can be a challenge. You can still leverage Workspace Control in newer versions of StoreFront by treating the published XenApp desktop the same as an published application. Maybe the new Flexcast Management Architecture (FMA), which is part of the upcoming Excalibur release, will change the way how we deliver and reconnect to XenApp published desktops so Workspace Control isn’t necessary anymore to control the user sessions, in the mean time you can either use Workspace Control in combination with session limits or RES session guard to optimize the user experience and control the amount of user sessions in your XenApp farm.

Please note that the information in this blog is provided as is without warranty of any kind.

Citrix UPS is awesome, but maybe it arrived too late?

Citrix Universal Print Server (UPS) is awesome, but maybe it arrived too late?

First I wanted to say that I think the Universal Print Server (UPS) is a really great feature, for those who doesn’t know the UPS feature yet, it’s build on the proven and evolved Universal Printer driver from Citrix which is used for client printer redirection for a long time, with UPS this Universal printer driver is extended to network printers also. UPS consist of a client component and a server component which you install on the print server.  I will not go into technical details about UPS, this is pretty much covered here.

While the Citrix UPS solves a lot of printing horror (think of unstable printer drivers, driver replication issues, print spooler crashes)  I do think we needed the Citrix UPS a while ago harder than we do now, this is mainly because of the following evolutions in the printing space :

1: Follow me printing concept
I see more and more customers that are moving towards a follow me printing concept, in this concept the user is presented with one print object (may be more if you want to preset printing defaults), when a user prints to this object the job is queued on a central print server, the user walks to the nearest printer and types in a code or provide a token\card and after that the print job is send to the printer, this concept has the following advances :

– User can walk to the nearest printer (no more connecting printers based on location or group)
– The user can take away confidential documents immediately
– Monitoring print behavoir and charge-back functionality
– And of course where this blog post is about : There is only one driver needed to connect to this printer object

To illustrate the follow me printing concept, I added a picture from Konica Minolta :

2: Universal Printer Drivers from the printer manufacturer
Yes there where (and maybe still are depending on the manufacturer) a lot of issues with universal  printer drivers, but the fact is that they are getting better and have broader support for different platforms and printing devices. The reason to use Universal Printer drivers from you manufacturer is simple :

– One driver to maintain
– Supports a wide range of print devices from the same manufacturer

3: Printer Driver isolation
Last but not least, in windows 2008R2 and Windows 7, there is a mechanism called printer driver isolation. Printer driver isolation means that the printer driver is isolated (Duh) from the print spooler and optionally also from other printer drivers. In this way a single bad printer driver cannot crash the entire print spooler, one side note is that your printer driver needs to support this isolation. If you never have looked at this feature, you should definitely do this because it can be a real life saver when you have a lot of printer drivers to manage.
While this is a nice build-in feature, it’s a little bit working around the issue so it’s not a reason to not look at better solutions like the Citrix UPS or option 1 and 2. The following isolation modes can be selected:

Driver-isolation mode Meaning
Shared Run the driver in a process that is shared with other printer drivers but is separate from the spooler process
Isolated Run the driver in a process that is separate from the spooler process and is not shared with other printer drivers
None Run the driver in the spooler process


Conclusion:
I’m sure there are a lot of good use cases for the Citrix Universal Print Server feature, and it’s even getting better in version 2 when there is also support for advanced printer properties.
For example it uses some nice compression technology between the client and the UPS, so if you are connecting to print servers over the WAN you better start looking at the Universal Print Server!

But on the other hand I do think the Universal Print Server arrived too late, we needed the Universal Print Server much harder a while ago then we do now because of the evolvements in the printing space I summarized in this blog.

The mystery of the Citrix Interceptor BHO

The mystery of the Citrix Interceptor BHO

When there is a new fix or update released for a product I am working with frequently, I always like to read the release notes to see what has been fixed or what kind of new features has been added. This helps in calculating what kind of impact the fix\update will have when installing it in a environment. It frustrates me when there is new functionality added that is not listed in the release notes, and to make it worse when a production environment is suffering because of this.
This is exactly the case with the Internet Explorer Add-On from Citrix called the Citrix Interceptor BHO. (BHO = Browser Helper Object)

This Citrix Interceptor BHO is automatically added through one of the following ways :

CtxVDAIEInterceptorBHO Class installed through Hotfix 025 for XenApp 6.5

CtxIEInterceptorBHO Class installed through Citrix Receiver 3.2

When one of the above is installed, you will likely see popups  when opening Internet Explorer to allow this BHO and its components to load outside of Internet Explorer protected mode.
If you were lucky you spot this popup when going through a test procedure, but if Internet Explorer was not on your test list you will get a lot of calls to the support desk from frustrated users.
Imagine that your users (or worse some management staff) ask you what this Internet Explorer Add-on is about and you cannot really give a good answer to it, will they take you serious about the things you are installing in a production environment? I think this is really bad…

Neither the release notes of Citrix Receiver 3.2 or XenApp 6.5 Hotfix 025 has some details about this BHO, it looks like it’s kept top secret, the only information from Citrix I could find is the following :

“In recent releases of Citrix Receiver for Windows, Citrix has implemented a new Browser Helper Object (BHO) – CtxIEInterceptorBHO (IEInterceptor.dll). This BHO does not currently provide any additional functionality for the majority of customers running XenApp or XenDesktop and is actively used only by certain XenApp Cloud Service Provider customers.”

Ok so it’s not used for the majority of customers running XenApp or XenDesktop, only by certain XenApp Cloud Service Providers… Why is it (already) added to a public release of Receiver and a public release of a XenApp hotfix with so less information provided?

I think only Citrix can answer this question, my guess is that the BHO adds functionality for some reverse seamless\content redirection functionality from project Dorado and that Citrix will keep this secret till the functionality is officially announced (maybe with the release of XenApp 6.5 Rollup Pack 1)

Since there is so little information about this BHO, I now choose to disable this add-ons entirely till there is more information about it from Citrix. The BHO add-ons can easily be disabled through a group policy see this CTX KB for more details on how to do this.
In this way it’s easy to enable the add-on again when Citrix comes with more information about the BHO and you decide you want to use it.

In a previous blog I wrote a workaround to get rid of the annoying popup in IE and enable the BHO and its components for everybody, but for now I would advise to disable the Citrix BHO entirely till Citrix comes with more information about it.
If someone has additional information about the interceptor BHO please let me know.

Please note that the information in this blog is provided as is without warranty of any kind.

Adaptive Display, what’s in the game? And do we need to fine-tune?

Make sure to also check this blogpost about a very handy tool named Remote Display Analyzer

In this blog post I wanted to talk about Adaptive Display, this new HDX feature is now available in both XenDesktop 5.5\5.6 and XenApp 6.5 (through a hotfix), Adaptive Display is the successor of the highly successful Progressive Display SpeedScreen technology, and it’s switched on by default. It’s an awesome technology because it is auto adopting to changes in the available bandwidth.

There is not so much information in the Citrix Edocs about fine tuning Adaptive Display, this is mainly because it’s auto-tuning and in various blog posts from Citrix they are saying the following :

“Progressive Display requires creating complex policy configurations to get it right making it a hard to use feature. Adaptive Display eliminates the need for such complex configurations and provides a fantastic out-of-the-box experience, making it zero configurations for Citrix Administrators”

Ok that’s fine by me, so we do not have to create complex policies anymore for LAN and WAN use cases, because it will detect the available bandwidth and adjusts accordingly. Super!
But what is exactly going on inside the Thinwire channel?
Before I go further, let’s summarize the default settings that are adjustable within Adaptive Display :

Adaptive Display Setting

Default Value

Max frames per second 24
Target Minimum Frame rate 10
Minimum Image Quality Normal
Moving Image Compression On (Enables or Disables Adaptive Display)
Extra Color Compression Default Off and enabled when bandwidth is below 8192 KBps
Heavyweight Compression Default Off
Lossy Compression level Default Medium, the default threshold is unlimited

* Note:  At this time, not all Adaptive Display policies can be configured using the XenApp 6.5 AppCenter console. Use Windows Group Policy Editor (gpedit.msc) instead.

Ok so now we know what settings are in the game of Adaptive Display, how are this settings come together? To make this more clear I made some drawings and explanations.

Let’s begin with the Extra Color Compression setting,  Color Compression takes advantage of the fact that the human eye is less sensitive to color information (Chroma) than luminance (Luma). When images are encoded with less color information, the bandwidth savings are huge yet the human eye still sees a very satisfactory picture. Most of today’s digital cameras use this technique to save on storage space. Extra Color Compression is turned on by Adaptive Display when the default threshold of 8192 KBps is reached, let’s picture this default behavoir :

Ok moving on to the Minimum Image Quality setting, this setting sets the JPEG quality floor.
In other words, this is the minimal acceptable JPEG quality, the following minimum quality levels can be set :

Minimum Image Quality

JPEG Quality

Ultra High 80 (highest image quality, lowest Compression)
Very High 55
High 30
Normal (Default) 20
Low 15 (Lowest image quality, Highest Compression)

The Lossy Compression level set’s the starting JPEG Quality, Adaptive Display adjusts the JPEG quality between the starting point to the Minimum Image Quality based on the bandwidth available to try to keep the frame rate from decreasing. The default starting JPEG Quality is 55 (Medium). Ok let’s picture this combination :

Notice that the default Lossy Compression level is set to Medium and the threshold to enable Lossy compression is set to 2147483647 KBps (unlimited), which means that this setting is always on.
The following Lossy Compression levels can be configured :

Lossy Compression Level

Starting JPEG Quality

High 25
Medium (Default) 55
Low 80
None 80 (Lossless)

Ok now we know what the default settings are and how the frame rate and compression is dynamically adjusted by Adaptive Display.  So what about this default settings, should we change it or leave it alone?
As usual it depends on the use case 🙂 but read on….

There is a great tool from Citrix called HDX Monitor, this tool lets you see all the HDX aspects in an active ICA session. If you start the HDX Monitor (with the default settings in place) you will see the following screen :

Ok looks good, but what’s that big red cross? Let’s find out :

Error : Image compression is not tuned to the available bandwidth. An Administrator can improve the user experience by creating a policy that optimizes image compression.

Ok so it looks like the HDX monitor engineering team is not happy with the Out-of-the-Box experience settings from the HDX Adaptive Display engineering team 🙂
I think the HDX Monitor engineering team is right, because if we connect through a fast LAN connection the default Medium compression is used and the windows flag background and other images looks like this :

This is not the best experience you can get with LAN conditions.
Why did Citrix choose this default Out-of-the-Box settings? I think because of a combination between the following 3 points :

1: User Experience
2: Server Scalability
3: Bandwidth Scalability

The default settings also improves the performance on the LAN when viewing high resolution photos etc, if you enabled Progressive display  in the past your users might already be used to this compression level.
But we can consider to improve the user experience for LAN scenarios by lowering the Lossy compression level or turning it off. This can be done in 3 ways :

1: Configure a Lossy Compression maximum threshold

The default threshold for Lossy Compression is set to unlimited, so by default Medium compression is always used. We can change the maximum threshold so we can give it a maximum  value in KBps, above that threshold Lossy Compression will be turned off. This looks like this :

As you can see the Lossy Compression will be turned off when the maximum threshold is reached, for example you can set this threshold on 75% of your LAN speed. The side effect of this one, is that you don’t have any Lossy Compression at all when the Bandwidth is above the maximum Threshold. This can be negatively impact your environment with a lot of LAN users viewing high resolution photos.

2: Set the Default Lossy Compression to Low

If we want to improve the user experience on the LAN, we can also lower the Lossy Compression to the lowest level. This looks like this.

Keep in mind that Adaptive Display will try to maintain this starting JPEG Quality also for your WAN users.

3: Configure different Adaptive Display policies and filter them on IP address

This one is a little bit the same as we configured for Progressive Display in the past.
Make a policy which applies a low level of Lossy compression for you LAN users and filter them on internal IP ranges and give it a higher priority then your default policy.
You can let the default policy (which applies to all users) default or change it with higher compression levels. In this scenario we only give the LAN users a higher starting JPEG quality.

Conclusion :

Do we need to fine-tune Adaptive Display?
I think we need to take this into consideration depending on the use case, for example :
– Do your users need to see lossless images on the LAN?
– Is your environment (Network, Servers, Client Devices) fast and scalable enough?
I also think the default Out-of-the-Box configuration is fine for most environments, but as you can see there are possibilities to change the default behavoir of Adaptive Display slightly to fit your needs.
You can do this by changing the compression levels and telling Adaptive Display what’s the starting JPEG Quality and the Minimum acceptable JPEG Quality.

What do you think? Please leave a comment on your thoughts.
Please note that the information in this blog is provided as is without warranty of any kind, it is a mix of own research and information from the following sources :

Citrix Edocs “Configuring Adaptive Display” (Contains wrong information about the default Lossy compression level values)
Citrix Blog “Dynamic Color Compression”
Citrix Blog “Introducing Adaptive Display”