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!

Advertisements

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 XD 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.

3 tips to harden your XenApp\RES environment

safe** This post was updated on 13-5-2013 and contains, besides additional information, also statements from RES Software. They responded very quick on the outcome of the security audit and would like to thank them for the nice collaboration **

Lately I was involved in a security and penetration scan at a customer servicing in Healthcare, because they store privacy sensitive information they need to apply to certain security regulations which are audited on a regular basis. Based on the results of this scan I will provide some findings and tips that you can use to further enhance the security of your XenApp environment. This tips are primarily focused on XenApp in combination with RES Workspace manager, but elements can also apply to other environments containing other UEM products.

Lets begin with a short description about the security scan :
The scan was performed by a company specialized in IT related security audits, you can also say the scan was performed by a group of legal hackers 😉

The security scan consisted of 3 parts :

1: Scan from an unauthorized internal perspective  (plug in the UTP cable and see how far you can get without any account)
2: Scan from an unauthorized external perspective (try to gain access from outside the corporate network trough external components)
3: Scan from an authorized user perspective (logged in with standard user credentials and see what kind of damage can be done)

Part 1 consisted of multiple scans for weaknesses like missing patches and gathering NTLM hashes to decrypt passwords etc, keypoint here is to consider disabling cached credentials for internal pc’s which doesn’t leave the building or limit the amount of cached credentials (the default is 10 cached credentials on Windows). And of course use strong passwords so when they have access to the hashes the decryption is very time consuming. They use different tools and methods to decrypt hashes, one of them is John the Ripper and pre calculated rainbow tables. When they got access to the password hashes its amazing (and scary) how fast the hash can be decrypted into a plain text password.

Part 2 consisted of a DNS lookup to gather information about external accessible elements of the infrastructure, after they are identified they try to logon using default user names and passwords and scan for other weaknesses. This customer uses Netscaler in DMZ in combination with SMS Passcode authentication, so they didn’t come far on that part. What should be taken into account is webmail\active-sync traffic (which often doesn’t have 2-factor authentication) in combination with password lockout policies, a hacker can perform a denial of service by trying lots of different usernames and wrong password to intentional block users in AD (especially admin accounts).

Part 3 consisted of tests on the XenApp environment while logged in with a normal user account, the following tips are derrived from findings in this part of the scan.

Tip 1: Timing

The first tip is about timing, if you are like me you want to put all of the user environment settings such as policies, registry and application settings as much as possible in RES Workspace Manager. If you are configuring things outside Workspace Manager, you lose the single point of management and that’s one of the key points the customer invested in RES Workspace Manager.
Well there is absolutely nothing wrong with that, but I will give you an example to think about when security is high on your design checklist.

Imagine that the company’s policy is to block the task manager from running in a user session, to do this you can import the CtrlAltDel.admx policy in RES Workspace Manager and disable the Task manager there. This policy backed with the fact you have appguard running in the background to block all unauthorized processes (so also task manager) you should assume it’s absolutely not possible to start the task manager inside the user session, at least I thought so till a saw the security report that proved otherwise…
What they did was fairly simple, consider that RES Workspace Manager by design removes all policies at logoff and that it takes some time (seconds) that the policies are applied and before appguard is fully functional when a user logs on. While the workspace composer does its magic, it seems possible to start the task manager through the CTRL-F3 hotkey right after the session is launched (press the hotkey repeatedly after the session is launched). See the following screenshot how this looks like.

WM_Timing

After Task Manager is launched, RES Workspace manager completes the workspace with all policies and rules so starting any unauthorized processes through task manager isn’t possible, but users can see information you rather want to hide (like performance, who is logged on etc). But besides that when you click on browse in task manager before the Workspace Composer applies the drive restriction settings it is possible to browse the C Drive even when you strictly prohibited this in RES Workspace Manager :

browsing

Workaround :

If you (or your customer) don’t care about users accessing task manager and local drives, there is absolutely nothing you have to do here, but if the company’s policy is to strictly hide task manager and to hide and prevent access to local drives, you can do the following things to overcome this timing issue :

–  Apply the task manager policy through AD, this policy is applied in an earlier stage when a user logs on so passing the hotkey at session creation has no effect
–  Consider using desktop viewer, if you use desktop viewer it’s not possible to pass hotkeys
–  Modify the default ica file on the Webinterface\Storefront server and disable hotkeys there (Thanks Kees Baggerman for pointing this one out!)

RES Software statement :

The timing issue with taskmanager will be fixed in a upcoming service release of RES Workspace Manager, expect a custom executable to test with shortly.

Tip 2: Macro security

Another way to bypass the application guard is to run processes inside memory of other (allowed) processes. This is often done through Office, because most of the time this processes are marked as trusted and malicious code can be easily fired of using macro’s. The Office KAT excel sheet (sources are at the bottom of this post) is an example of a sheet containing such macro’s. When opening Office KAT in a user session with default office settings, the user is prompted to allow the macro’s (message is in Dutch but it says : warning macro’s are turned off, enable content to turn them on) :

Office KAT

When the content is enabled, we click on “open command line” and we are prompted with the following message :

run_in_memory

After clicking OK, the command prompt is started, in the following screenshot you can see that the actual process is Excel.exe, you can also see that we can easily switch to the C drive and browse through the contents of the XenApp server (note that drive restriction policy are ignored) :

cmd_content

(Please note that this user session hasn’t got access to the command prompt and that access to local drives are strictly prohibited).

And when we click on “open regedit” from Office KAT, which launches a registry editor under the Excel.exe process, you can see how simple it is to browse the whole registry of the XenApp server :

regedit

After chatting with Kees Baggerman about this topic, he pointed me to a similar Excel macro from Remko Weijnen, Remko was the first pointing out that there was a way to bypass the application guard by running untrusted processes in memory of authorized processes using a Excel macro. You can read about it here. This was one of the reasons that RES tightened the security rules of the application guard driver, they did this by blocking the svchost process from running other (unauthorized) processes indirectly. This security enhancement is available since Workspace Manager 2011 SR4, the following rule is created (and disabled) by default in new RES Workspace Manager deployments :

svchost

Note : Check this rule out if you upgraded your environment till this point, because during upgrade the rule is created and enabled by default, this is done to avoid security warnings thrown at your users after the upgrade, you can run the rule in logging mode for a while to identify what the impact will be in your environment. So if you want to harden your environment you should disable this rule.

Another way to tighten the security of your RES environment is by restricting a managed application to be only launched by Workspace Manager itself (see below screenshot). This prevents the managed application to be launched through other applications or unmanaged file types. This example video contains Remko’s macro in combination with this setting, you can see that the authorized process (excel.exe in the video example) isn’t started by RES Workspace Manager itself and thereby blocked from launching after this setting is active.
security
Back to the Office KAT sheet which was used in the security scan, I tested all of this security settings in combination with Office KAT and it happens to be that I could still run the CMD and Regedit instance, I think this is because the macro’s in Office KAT starts a different embedded CMD instance in memory (ReactOS) without reading\executing anything from disk. I think this is why application guard cannot detect it, and this would probably the moment where the virusscanner should kick in.

Does it mean that malicious macro’s like Office KAT can put your environment in direct danger? No not really because we still have only user rights and any processes launched from the command prompt will be blocked by appguard. But what might be a risk is that the content of the local drives and the registry is exposed which may contain sensitive information about your infrastructure. Besides that there is another risk in the way how the default file system in Windows is designed, Tip 3 will go further on this subject but first : how can we prevent this kind of Macro’s from running?

Workaround :

– You can define trusted locations (Office 2010 and above) and run unsigned macro’s from there, when using trusted locations the Trust Center security feature is bypassed, but please note that Office KAT isn’t noticed by this feature so I wouldn’t rely on this feature only
– You can disable all macro’s through a policy or only allow signed macro’s
– Some virus scanners (also windows defender in Windows 8) detects Office KAT as a thread and places the Excel sheet in quarantine, but there are more variants of this macro’s and not all virus scanners detects them, if you want to rely on the virus scanner pick one that’s designed to detect this kind of malicious macro’s. Also be careful with stripping your virusscanner to optimize performance, it maybe you win on performance but on the other hand you might lose on security.  You can download Office KAT at the bottom of this post to check if your virusscanner detects it.

RES Software statement :

This kind of macro’s, which runs malicious code totally in memory (ReactOS in this case), is out of the scope of RES appguard, this type of macro’s should be detected by the virusscanner. (They added to this that there will be an even more tighter security mechanism in the current under development .net version of RES Workspace Manager).

Tip 3: File system security

So in Tip 1 and 2 we found possible ways to get access to the local drives of the XenApp server even when access to them is strictly prohibited through policies. Besides exposing sensitive information, there is another culprit when users have access to local drives : The default ACL’s in Windows allows users to create folders on the local drives and store data in it. See below an example of CMD running under the Excel process, creating a folder and store data in it :

cmd_edit_content

You can imagine that users (or hackers with user rights) with bad intentions can make a mess of your XenApp server and even worse they can fill up the disk with data till the disk reaches full capacity which can result in a denial of service. The benefit of using provisioned XenApp servers is that they revert to a clean state after each reboot, but the risk stays the same and may be even worse because the write-cache will grow and you can end up with failing XenApp servers because the write-cache location isn’t sized for that. Also when using provsioning in combination with a local disk for the write-cache, the same default file system security applies to this disk. We can for example browse to the D drive and see the cache file :

cmd_vdisk_cache

By default users can create folders on this disk which will persist after a reboot, when this disk is filled with data the cache file cannot grow any further. This can affect the XenApp server during run time but also after a reboot!

Workaround :

I think the most recommended way to address this risk is to accept that users in some way can access the local drives of the XenApp server, you can hide them and narrow the risk that they can be accessed through Tip 1 and 2 for example, but it’s hard to totally prevent it. Some applications for instance doesn’t respect the drive restriction policies and can expose access to the local drives. To prevent write access to the local drives you can use the RES Workspace Manager security feature called Read-only blanketing (RoB), this feature transforms the local drives to read-only drives without messing around with the default ACL’s, it’s there in Silver (security) and Gold edition, so if you are not using this feature yet you might consider it! 

Conclusion :

In this blog post I showed you some simple tips to further enhance the security of your XenApp environment in combination with RES Workspace Manager. Hopefully this information was helpful for you when security is an important consideration in your environment or design. How tight you need to secure your XenApp environment depends on the kind of company and type of data you are securing. Most of the time the more secure you make it, the more complex it will become. It’s all about eliminating risks, but I think even more important : accepting risks.

With RES Workspace Manager it becomes a lot easier to harden your environment from a user perspective, use the security features and maybe more important audit this features on ongoing basis.

You can download Office KAT here, it’s part of the Interactive Kiosk Attack Tools (iKAT) which contains more useful tools to test the security of your environment. Please be careful browsing this pages because it can contains content and material not suitable for work.

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”

Popup in IE after installing Hotfix XA650W2K8R2X64025 and HDXFlash200WX64001 for XenApp 6.5

** Update **
Please read this blog post for additional information.

I noticed in some environments that after installing XA650W2K8R2X64025 and HDXFlash200WX64001 for XenApp 6.5 (wich fixes a lot of flash redirection issues in XA65) the users are getting an popup in Internet Explorer about the VDAredirector.exe opening outside IE protected mode :

(Screenshot is from a user with the Dutch language pack enabled)

English message :

This program will open outside of Protected mode. Internet Explorer’s Protected mode helps protect your computer. If you do not trust this website, do not open this program.

Name: Citrix FTA, URL VDA Redirector
Publisher: Citrix Systems, INC

Resolution :

After selecting “Do not show me the warning for this program again” and clicking on “Allow” i searched the registry and found the following key :

[HKCU\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\{BFFC40A2-FFE2-4E6F-B179-3641561D4FCD}]
“AppName”=”VDARedirector.exe”
“AppPath”=”C:\\Program Files (x86)\\Citrix\\system32”
“Policy”=dword:00000003

Import this registry key into RES Workspace Manager (loginscript or other environment manager software you are using) apply it to your users and they will not be bothered with this warning message!