Guest Blog by Jack Smith, System Engineer, Liquidware Labs
The thought of application layering opens up some very interesting possibilities. The obvious is injecting applications into desktops whether that be Virtual or Physical. What is often not though of is published application servers Citrix XenApp (and RDSH), for the remainder of this article I will refer to published apps as XenApp. This same issue comes up just the same as a desktop, the scale is reduced since there is fewer server images to maintain, but the issue is still the same. How do I put applications into the OS without actually installing them into the OS thus keeping the image as clean and dynamic as possible?
Think of this scenario, every Sunday (or more often) you reboot your server pools because that has been XenApp best practice for years. When you need to change your applications you open up your image, or in the case of non PVS/MCS you actually uninstall and reinstall/upgrade programs. Now that practice has been the normal way of updating applications for as long as the Citrix has been around. This again comes back to the same underlying issue of manually managing the XenApp servers the same way we have been always managing them. What I propose is using a technologies like Liquidware Labs FlexApp and using that as your application lifecycle mechanism.
Coming back to that reboot Sunday, on Friday you assign App Version 1.0 to your image, as the machine boots on Sunday the application is layered into your XenApp server and you are able to publish that app as if it was native since with FlexApp the application will run and function in that way, native. Two weeks later App Version 2.0 comes out and you would like to change that application with a minimal disruption to your environment. With FlexApp you can switch out App V1 with App V2 reboot Sunday happens as always and without even having to republish the application you now have version 2.0 available to your users. In this scenario there was no need to open the image, uninstall anything reinstall anything, it was a simple switch of applications and a reboot.
This option has a lot of possibilities in that you can now have more of a vanilla image to maintain across all your application pools. In this example you have three server pools with a similar underlying image that is being provisioned across a few different deliver groups. All with slightly different apps assigned to them dynamically. There is no need to maintain three different images just for application differences, you just layer the apps you need into the servers that need them.
Theses can also be the same apps you use for your desktops, as long as the OS architectures are similar (Win7/2008 & Win8.1/10/2012). You can then use some applications in your XenApp as well as using them in your XenDesktop or physical desktops. There are some use cases where this makes sense. For instance if you have a GPU intensive applications that you would like to run on physical desktops with GPU cards, but want other apps supported in XenApp. Between the two OS types you would like adobe reader installed, this part can be handled in layers.
Beyond the simple layers ProfileUnity can handle things I like to call “fix em ups”. This is where you can add in regkey or file copy processes to change how the application is set based on the context of where the application is hosted. This is again the same application layer being used in your XenApp farm as well as the same app being used on your desktops, but the context is different and with our having to maintain two different versions of this app you can add in the “fix em up” into the user space (HKCU) this will change a user based settings all around the context of where the user is using the app. All these things can be possible when you have the ability so seamlessly tie your application layer system with your user environment management tools.