Introduction
Whilst more and more organizations have made the jump from XenApp 6.5 to 7.x, it seems many more are still hanging around on 6.5 or even earlier versions. While I don’t agree with doing that, I can understand it. With all of the work and revs that went into 6.5, it was a very stable and reliable product. It seems to me that most middle to large sized companies used XenApp and I would hazard a guess that most used 6.5 at one point or another. Defacto, many IT professionals have experience with XenApp 6.5, they like it and they are comfortable with it.
I won’t lie, making the transition is not easy. Even just navigating around Studio compared to AppCenter can be an aggravating experience. My first exposure to 7.x was XenDesktop 7.0 in 2013. (I say XenDesktop but I mostly worked with the app publishing piece and yes, there was no XenApp 7.0, it was just part of XenDesktop which just added to people’s frustration) I must say, I didn’t like 7.0. I couldn’t get my head around the structuring of Machine Catalogs and Delivery Groups. The ambiguity in the UI when trying to add session hosts to groups. The lack of Zones. Needing to add columns to the sessions view to see what app users were running. With the huge gap in terms of feature parity with 6.5, at that time, I wouldn’t have advised a friend to use the product.
My next exposure was with version 7.8. I still wasn’t a fan of the product. It was very buggy. Next, I spent some time working with version 7.6 LTSR and oh, boy was that buggy! In fact, I think hours and hours of my time troubleshooting with Citrix support and likely others in the same boat is probably a big reason why 7.6 CU4 is a pretty stable release.
In this post, I am not going to go through architecting a new 7.x build.
One of the strengths of Citrix is its awesome user community. There is a lot of great info out there from CTPs, CTA and others in the community, as well as on Citrix’s own blog.
I recommend checking out:
Quick Server Sizing for XenApp 7
Estimate the Size of XenApp & XenDesktop Monitoring Database
Step by Step Setup Guides by Carl Stalhood
The Ultimate XenDesktop 7.x Internals Cheat Sheet by Bas Van Kaam
Scripts and Other Utilities by Carl Webster
NetScaler, IoT, Citrix in the Cloud and More by Dave Brett
Citrix Performance Considerations
Citrix Printing Best Practices
This post is going to contain some of my tips and lessons learned to hopefully make your migration easier.
To LTSR or Not to LTSR?
Today, Citrix announced 7.15 is now considered LTSR.
If you are considering adopting the Long Term Service Release version, you may likely think doing so will ensure you are on a stable version and will have less frequent updates. As of this post, before today the LTSR version was 7.6 CU4. This means really there was 5 iterations for that LTSR. Having worked with that version, I found 7.6, 7.6 CU1 and CU2 had many bugs. CU3 is when it became a more stable release.
7.6 CU4 was also a pretty stable release. Unfortunately, in terms of feature it paled in comparison to the CB release. You will notice at a glance when comparing Citrix Studio 7.6 to later versions, several features are missing:
When choosing to pick LTSR, you must also be willing to miss out on new features which come in the current branch. Less of a concern right now if adopting 7.15 but keep in mind, 7.15 will likely be LTSR for some time as is the nature of LTSR so future new features will get released and if you are on 7.15 you may miss out.
Another consideration is that LTSR is fraught with complications. When working with 7.6, I discovered several bugs which required private hotfixes from Citrix. Due to the timing of some of these hotfixes, they were provided just before a new CU was released. This meant us having to stay on a different CU due to our private hotfixes not being included in the update. This was a very painful process. To read about just one of awful issues I ran into, check out my post on Zombie Sessions!
I’m hopeful the pain felt with 7.6 LTSR won’t be repeated with newer releases as the user base for 7.x is larger than it was when 7.6 was released. Citrix has had more time to patch holes in the product and add back lost features.
I think your decision on whether or not to go with LTSR or not should be based on your environment. Do you have any 3rd party apps which require LTSR for support? If so, go with LTSR. Do you work in an environment which is a little averse to change? If so, go with LTSR. If you prefer to avail of new features as they come out and have less concern about more frequent updates, go with CB.
What the Hell do I do With These Delivery Groups?
If you are new to Citrix Studio and spent most of your time working with 6.5. You may be pretty confused by the workflow of Machine Catalogs and Delivery Groups. If you moved to early released of 7.x you are also likely pretty bemused by the lack of Zone and a bunch of other features you loved in 6.5.
When you get started, create a machine catalog. You could create one machine catalog for all machines or possibly create multiple. One for each unique image or OS type.
Once you have your machine catalog, you can add your session hosts which have the VDA installed into the catalog.
Create a Delivery Group and when at the point of the wizard for machines, you can add the number of machines you want to add to this group. I really don’t like this part of the flow. There is very little control of which servers will get added to the group when using the wizard.
For first timers, another confusing aspect is that you can restrict your Delivery Groups. It’s important to know that when adding applications to a Delivery Group, they default to allow all users in the Delivery Group access to the app BUT
You can also limit visibility of the applications themselves. SO, you can allow all domain users visibility to all of your delivery groups and then just limit visibility of each app to only the users which require them. Alternatively, if you have a limited number of users in your organization who require remote access, you can limit your Delivery Groups to those users and then limit on a per app basis. Or if for some reason you want all remote users to have access to all apps you could assign them to the Delivery Group and allow all Delivery Group users access to the apps. That way you don’t need unique AD groups for each app.
You can select which flow works best for you.
An extra feature in 7.x is Storefront filters. You can hide certain applications using a string based filter in the application properties. For more check out these articles: https://www.citrix.com/blogs/2014/03/27/hiding-applications-in-citrix-storefront/ and https://www.citrix.com/blogs/2014/05/20/now-you-see-me-now-you-dont-a-guide-to-hiding-published-resources/
Is Director Worth It?
I believe: “If you own it, use it”. I am not a fan of Citrix Director either as a monitoring and troubleshooting tool or as a management tool but it can be pretty useful for a quick real time glance at the health of your environment and to gauge the possible end user experience. It’s also useful in a pinch for carrying out certain admin tasks without needing to get into PowerShell or Citrix Studio.
You can provide your Help Desk Administrators access to Director with limited rights. This can be good for killing processes which may leave a user’s session hung, resetting a user’s profile and more. In earlier versions of Director, I feel the level of control over what those in restricted roles could do was lacking. E.g. you couldn’t allow them to do x without also allowing them to do y and when y was rebooting a session host, that wasn’t a risk worth taking 😀
I feel like Director improved with 7.14 and appears to have got a pretty nifty new application failures trend dashboard.
In my opinion, Director is nowhere close to being as good as 3rd party tools like those from Goliath Technologies, EG Innovations, ControlUp, Liquidware, ExtraHop etc. BUT like I stated if you already own the product it can provide value.
What Is The Best Way to Deploy App-V with 7.x?
It may be due to App-V being my bread and butter but to me, the App-V integration in 7.x is one of the least useful features in the product. Prior to 7.11, the only integration within Studio was to Add Publishing Server. You can review my previous post on why the App-V Full Infrastructure is not advisable. In short it’s not very scalable and unfortunately, the way the integration is setup it’s very difficult to integrate the full infrastructure in a way with scalability and redundancy.
In versions prior to 7.8, App-V applications published with the /appvve: parameter wouldn’t work properly.
In version 7.11+ a new feature was included the ability to just add packages directly from your App-V content share. The DDC would then copy your app(s) to C:\Windows\Temp\CitrixAppVPkgCache and publish to the hosts in your Delivery Group by executing some PowerShell cmdlets e.g. https://citrix.github.io/delivery-controller-sdk/AppLibrary/New-AppLibAppVPackage/
I have tried this feature in version 7.11, 7.12, 7.13 and 7.14 but have encountered problems in all versions. In some cases, application not launching when deployed with this option but working fine with added and published on the host using the Microsoft provided PowerShell cmdlets and some dumber things like shortcut icons missing.
Transitioning Your Users from Your 6.5 Farm to Your 7.x Farm?
It’s advisable to take a measured approach to migrating your users from your “legacy” farm to your new farm. Luckily, you can publish your applications which run in your 6.5 farm through your new Storefront store.
This is just smoke and mirrors. There is no lift and shift going on here. The applications are still present and running from your 6.5 environment. StoreFront is not publishing the applications, it’s just connects to your legacy farm, enumerates the applications there and lists for the assigned users.
To allow StoreFront to connect with your legacy farm, add the farm in StoreFront.
Easy, eh?
The difficulty transitioning your users will actually be in moving the applications into your new farm and educating users to the upcoming changes.
For this, my choice is to virtualize the applications but how you package and deploy your applications to your servers is up to you.
If choosing to update an application during the farm migration, you may have a need to have both the older version of the app published in StoreFront running in your old farm and the updated version running in your new farm both published alongside each other for an initial transition period. This is pretty common. I created a pretty useful script which I ran as a scheduled task every couple of hours when ready to move the bulk of users to the new app. (It’s a bit funky because it was reading a list of app users from a text file due to the 6.5 box being in a different domain than the scripting server) This would send a canned message to users of the app in 6.5 to ask them to use the new app. Once all users were out, we disabled the old app and left only the new version.
I also have a similar script which I use in 7.x when migrating from one version of an app to another: Message App Users in 7.x
Much like my performance considerations blog post, I expect this post to grow over time.
