HDX Graphics Policies, really are simpler than you think!

A wrote a blog a while ago (read it here) about how although the Citrix Studio Console interface shows every policy for every graphics mode, most modern graphics modes need very little configuration and are affected by a few policies only. The majority of policies are actually associated with the Legacy Graphics mode (designed for use with Legacy OSs such as win7 and 2018 R2 and earlier), so in the future on modern OSs there is far little to configure.

Long term, it would be ideal if the Studio interface was redesigned to make this more transparent, I think it was assumed that because each policy is self-documenting users would read the legacy ones and realise they were not applicable, I’m not convinced this is the case. Many of the policies “sound” useful.

A few weeks ago I read a blog by a Dutch user trying out the new “Thinwire Compatibility” mode (read about it here), since writing about this I noticed that many of the policies he set were inapplicable to that mode. It’s very common to see this is customer deployments, admins fiddle and if they see no ill-effects often leave policies, or policies from old deployments get transferred to new deployments without review.

Use Templates to make it simple

To make it simple, XenDesktop / XenApp 7.3 FP3 introduced templates which provide collections of policies administrators can load to obtain a deployment tuned for various use cases, we would always advise users consider using a template before fiddling with individual policies. You can find out more about templates, here: https://www.citrix.com/blogs/2015/10/28/simplify-hdx-policy-administration-to-amplify-the-user-experience/

New whitepaper – which policies apply to which graphics mode

A new article, CTX202687 – HDX Graphics Modes – Which Policies Apply to DCR/Thinwire/H.264 – An Overview for XenDesktop/XenApp 7.6 FP3, has just been published which covers which policies apply to which graphics modes as well as the precedence hierarchy and receiver dependencies for those graphics modes. If you read this paper you’ll realise that most modes have 5 or less tuneable parameters (some have just 2!).

Please read the CTX if you are unsure on which policies to set!

>>> READ IT HERE

13 thoughts on “HDX Graphics Policies, really are simpler than you think!

Add yours

  1. Thank you for sharing this, Rachel. The CTX202687 article is really a very nice compilation of just about anything and everything you need. Tweaking parameters is always interesting, but time and time again it’s generally much esaier to support standard configurations, especially when they do as well as they do already right “out of the box”. It also makes troubleshooting and support a lot easier if you have a uniform environment. Finally, the protocol selection made for you are different now in some cases between the XD/XA 76.6 FP2 and FP3 releases, so before going hog-wild with tuning, I’d certainly recommending trying one of the standardized deployments first.

    Like

  2. Really good stuff Rachel! As always, thanks for bringing the knowledge to the masses. I’d love to see this sorted/filtered better in Studio and GPOs, but hey I guess we can’t have everything!
    Great work, keep it up!

    Like

  3. HDX graphics policy. I really like the new templates, they make it much easier to work with now. There are so many ways of tweaking and its all about providing a simple configuration based on requirement and Citrix have now made it much easier in this complex technology of many choices. Great work Rachel. keep up the good work. I personally like using HDX monitor from Taas to troubleshoot which codec that a client is using.

    /Poppelgaard

    Like

  4. Thomas, you’ve got to start calling TaaS “Insight Services”. Now repeat after me, 10 times, “I n s i g h t S e r v i c e s …” 😀

    Like

  5. I’ve been arguing for years that setting graphics policies is too confusing for the novice Citrix admin and until recently was poorly documented. Even the more experienced guys still get caught out as you’ve noted above with Patrick. It would be great if the Studio policy interface could allow you to select a particular graphics mode, then automatically grey out the non-applicable settings.

    Like

    1. I actually suspect PAtrick didn’t get caught out but was using a fairly common technique employed by experts (Jason from NVIDIA did it in his template here: http://discussions.citrix.com/topic/357800-template-exchange-studio-templates-%E2%80%93-help-needed-out-of-the-box-configuration-for-xendesktop-and-xenapp/) whereby those running legacy and other sessions often add the policies for both to a single template and then flip legacy on and off. For the new user and transparency we are trying to avoid this and do templates focused on use case using the a single mode and policies just for that. JAson’s modifying his templates to account for new policies and thinwire in FP3 so we are also looking at labeling templates for the correct versions.

      But yes for the new user/admin inheriting a configuration, where if you aren’t sure and it works don’t change it’s not transparent. Legacy policies only applying to legacy will be ignored if legacy off but still confusing.

      I hope until the Studio interface becomes more transparent and legacy goes away (which it will as 2008R2 usage drops off) the documentation/templates are seen as a positive thing. I wondered if even a button in studio “hide legacy policies” for admins who know using newer OSs and/or not legacy would be helpful. Actually labelling every policy per mode and determining the OSs and modes in use is actually architecturally challenging.

      Thoughts?

      Like

      1. There is fuzziness between ease of use and flexibility. Years ago, I studied whole books on tuning the Solaris OS because each environment was so different and it made a huge difference. After moving to Linux and now with pretty much self-tuning systems, all that became unnecessary (save little things like network parameters, the storage scheduler, etc,). Ease of use is a big plus, and unless you really know what you’re doing, tweaks are generally best left alone.

        As to backward compatibility, yes, the legacy setting should go at some point. We don’t support DOS 3,1 or XP anymore at our institution, and there is a time to let go of things that are outdated and only make it more work to carry forward. It’s shocking how many places still are running Windows Server 2003! The only way to get rid of some of these things is to cut them off. We are totally on 2012 R2 in my team now and never want to look back at even 2008,

        With new codecs and 4k video, things need to move forward, not remain mired in the past. Jason, I laud the thought of a special GRID setting. Whatever makes intelligent choices that benefit the customer and make it easier for all involved is good. The idea, Rachel, of hiding the legacy policies is an interesting one.

        One thing I’d like to see is perhaps tracking of the HDX connections in Citrix Studio so you can see what HDX protocol was established for each client (and be able to look back to see if the protocol changed at some point). It would make it easier to see when changes in policies take place, new templates are introduced, and assist with troubleshooting. It would be also nice to see at a glace how many connections are using which policy at a given moment so you could decide when, for example, less than 10% are using legacy settings to make a draconian decision to announce a phase-out time for supporting those.

        My $0.02′ worth, as always…

        -=Tobias

        Like

      2. Yes better visibility on graphics in our consoles is one we are looking at, it can be a case of at the time of negotiation. As a stop gap we find https://www.citrix.com/blogs/2015/01/30/site-wide-view-of-hdx-graphics-modes/ a really useful tool, run it occasionally and spot check your environment… then lets you ping all iOS users if you have an issue and see if others have it etc…. tools like this are our way of trialing ideas but of course everyone wants the good ones immediately when we do this….

        Like

      3. Yes, Amit’s script is useful for a one-time check, but not for looking at historical trends, so I’m pleased to hear this is under consideration. My team is actively working with Citrix on a 6-week monitoring project in conjunction with XenDesktop to help identify what new tools and metrics could be available to end users, so we’re pretty attune to this sort of thing at the moment. Smitha P is our primary contact person on this.

        Like

      4. Yes, PowerShell and cron to the rescue… 😀

        Really, it’d just be one more tiny flag to put in to the database and a small addition to the GUI.

        Like

      5. Small additions to the GUI require a console release and to pass the gatekeepers of product design, plus a vast deal of test…. so making sure the things added are useful by putting them out standalone to gauge feedback is becoming quite common… PD (product design) are reluctant to over complicate GUIs so evidence of use and the chance to revise before baked, the chance to demo customer demand … proves useful

        Like

  6. As Rachel’s pointed out, in the past I’ve used my “template” to cover all flavours of connection types. This then allows the template to be used as a starting point (I’ll always advise refining for a specific environment).

    At times though Admin’s will have no idea what devices a user will connect from and making a range of policies to successfully address these is fraught with challenges since it’s a known unknown… The recent updates in Feature Pack 3 have come a long way to helping simplify this, and along with some of the Citrix team we’ve been putting together a HDX 3D Pro template specifically for GRID.

    We should always remember that a template is just that, and is intended for further customisation. While possibly the biggest challenge in the past is having documentation that was publicly available explaining the settings, their relevance and their interaction this is improving and more information is being published with each release.

    And of course, as we spend more time refining and optimising user experience in these areas, we’ll always find points to disagree on. Seeing 15fps as a target frame rate makes me very sad… but there’s a time and a place for that setting and as long as when we create templates we explain the resoning for the value, everyone benefits.

    Jason

    Liked by 1 person

Leave a reply to Dane Young Cancel reply

Blog at WordPress.com.

Up ↑