Hello and welcome to Part 2 of a blog series about Citrix Cloud and the many features and benefits of utilising Citrix Cloud to design, implement, support and maintain your XenApp/XenDesktop environment.
To give you a bit of background, since joining Citrix as a Senior Systems Engineer for UK Enterprise customers, I decided to put a few articles together to help show the real power and use cases for Citrix Cloud (formally Citrix Workspace Cloud).
These articles are meant as an introduction to Citrix Cloud and a bit of a “How To” in deploying the basic functionally. These articles are by no means the “be all and end all” of Citrix Cloud nor do they represent any official training or documentation from Citrix.
In the series I hope to demonstrate some common use cases and how under the single solution of Citrix Cloud, these use cases can be met. It will go something like this:
Part 1 – using Blueprints to deploy a new Citrix XenApp/XenDesktop 7.x Site into Azure
Part 2 – using Citrix Lifecycle Management to automatically migrate your XenApp 6.5 Farm to your newly deployed XenApp 7.x Site.
Part 3 – using a customised Blueprint to install the XenApp 7.x VDA onto an existing XenApp 6.5 server
Part 4 – using Citrix Lifecycle Management Smart Scale to intelligently control your cloud-hosted workloads so that you only have the amount of resources up and running in the cloud that you are using.
Part 5 – using Citrix Lifecycle Management to Upgrade your XenApp 7.x Site to the latest version.
Part 6 – Using the Citrix Cloud Apps & Desktop service to manage your VDA workloads, wherever they are; be it on-premises, cloud-hosted or a hybrid for a fully cloud-managed solution. This solution removes the requirement to deploy the Control Layer, which Citrix will maintain for you. You access an HTML5 version of Studio for management. The only “deployable” components are the VDAs.
In Part 1, we looked at using Citrix Cloud Blueprints to deploy a small scale (POC) XenApp environment into Microsoft Azure. This blog post does follow on from that so it may be advisable to read up on how we created our XenApp 7.x Site first.
In Part 2, we will look at migrating our legacy XenApp 6.5 Farm to our newly created XenApp 7.x Site. We shall accomplish this using Citrix Lifecycle Management and the Upgrade feature. This will allow us to automate the whole process using PowerShell scripts and workflow to take away a lot of the manual steps and increase time to value of your XenApp migration.
So, for those who aren’t 100% familiar, when we launched XenApp and XenDesktop 7.x, this was a big shift for XenApp as the architecture changed completely from IMA (Independent Management Architecture) to FMA (Flexcast Management Architecture). One of the reasons was to simplify the delivery of apps and desktops through a single, common architecture – makes a lot of sense right? With this meant that if you wanted to “upgrade” your XenApp 6.x environment to 7.x, you would have to do a migration as there is no in place migration option which was and still is no simple task.
What I intend to show in this blog article is how we can use Citrix Lifecycle Management to do the “heavy lifting” and migrate all the settings across to the XenApp 7.x Site we created in the previous blog. By automating this task, you save a lot of manual work and reduce a lot of risk of a migration. Also, as it is a side-by-side migration, you would not effect the existing XenApp 6.5 production environment.
Here’s one I made earlier…
So, in order to show how the migration works, I’ve created a very simply XenApp 6.5 environment, pretty much akin to our XenApp 7.x environment. I have a single Windows 2008 R2 server for my Zone Data Collector and Web Interface.
I then have another Windows 2008 R2 server as my Session-Host (Worker) server with a few applications installed.
I also configured some very basic Citrix Policies, both Computer…
and User based…
As you can see with the User-based policies, I’ve deployed 3 from the built-in templates and one I’ve created manually. I’ve also applied a FILTER to the Remote User Policy based on the AD group SEC_CTX_REMOTE_USERS.
You can see if I log into my Web Interface, I can see the published applications.
Log into your Citrix Cloud portal and navigate to Citrix Lifecycle Management.
- From the Lifecycle Management menu, click on Update.
- Click on Migrations.
- Click Add Project.
- Name your project and in the case of a 6.5 to 7.x migration, select “XenApp 6.5 to XenApp 7.6” migration type. Please note that although it says XenApp 7.6, it works with any newer versions, such as XenApp 7.9. Click Add.
- Select Fully Automated as the migration type. I mean, why wouldn’t you! 😉
- You know get a nice visual of the migration process. Have a read and click Next.
- Now, I must admit I’m not entirely sure why but when I selected the option “Choose an existing deployment created with Lifecycle Management“, it didn’t find my deployment, even though I deployed via CLM. It is registered correctly… I’m still looking into this. Anyway, I then selected “Connect an existing deployment created outside of Lifecycle Management” and all was well. Didn’t seem to make any difference.
- From the dropdown, select your Resource Location. In my case it was my Azure Subscription.
- Click Select XenApp Controller.
- From the list I selected the Controller created by the Blueprint in my previous blog article; XDC.
- You are now prompted for credentials. Enter an administrative username and password. Click Save.
- CLM will now query the XenApp deployment and fetch the configuration.
- You’ll now see that the XenApp 7.x section is complete.
- Now it’s time to configure the XenApp 6.5 environment. From the dropdown, select your Resource Location. Again, in my case it is my Azure Subscription but this could be AWS, or an on-prem XenServer, Hyper-V or ESX location.
- As you can see, as we have a deployment created outside of Lifecycle Management, we cannot see our XenApp 6.5 Zone Data Collector (ZDC). The easiest way is to log into Citrix Cloud on our ZDC and run through this wizard. Select Cannot see controller server?
- You’ll now have the option to download the Lifecycle Management Connector. Click Download Connector.
- Save the CitrixLifecycleManagementAgent.exe.
- Now run the agent.
- Accept the EULA and click Install.
- Once, completed (takes a mere jot!), click Finish.
- If you open up the Services console, you’ll see two new services added; Citrix Lifecycle Management Agent Service and Citrix Lifecycle Management Monitor Service.
- Navigate back to Citrix Lifecycle Management GUI. Select your Resource Location. In my case, yet again (I promise I’ll do an on-prem XenServer deployment soon!) I’m using my Azure Subscription. Click Select XenApp Controller.
- You’ll now see the newly added ZDC! I was very original and called my CTX-ZDC-01. K.I.S.S. 😉 Select your ZDC.
- You’ll be prompted for adminy creds.
- Now you’ve connected to your Destination (XenApp 7.x) and your Source (XenApp 6.5), click Analyze XenApp Farm.
- You’ll get a progress bar that updates as it goes along.
- Once completed, you’ll see that it’s found your applications and policies. Click Next.
- You’ll first be presented with your applications. As you can see, it’s found 100% of all 4 of them!
- Select all the applications you wish to migrate.
- Now click on Analyzed Policies. Again we see all of the User Policies from our XenApp 6.5 farm.
- Select them all.
- You’ll also see all of your Computer Policies.
- Again, select them all.
- Once you’ve selected all of your required applications and policies, click Process to Migration (sum of apps + pols).
- You’ll now be prompted for a Delivery Group. You can select an existing group or in my case, select Create new delivery group (probably a preferred option). As you can see, it’s found the CLM-DemoDeliveryGroup created from our blueprint in the previous blog.
- Enter the name of the Delivery Group. I’ve kept the default of XenApp65. Click Migrate.
- Your farm settings will now be migrated and you’ll get a status bar to show you how it’s going. Coffee time! But be warned, this doesn’t take as long as you’d think 😉
- Once completed, you’ll see the log. As you can see from mine, the migration was completed with some warnings. When you expand the warnings, they can be ignored as they are for policies that have filters on them advising us to check that these have applied successfully (think of a scenario when you’re migrating within different domains) and for policies that contain settings that are not applicable. My Default Computer Policy contained XML settings – not applicable in XenApp 7.x and Licensing settings. Again, not applicable as a policy in XenApp 7.x Land.
- If we now go to Citrix Studio on our XenApp 7.x Controller (XDC), we can see the newly created Delivery Group by CLM with our migrated settings (see apps and user assignment).
- If we click on the Applications node, we’ll see the previously configured applications AND the newly migrated ones! Whooppie!!!
- Going down to the Policies node, you can see that all the User Policies (the applicable policies) have been migrated AND the filters have also been applied! Never doubted it 😀 !
- Just to double check, I confirmed that the “Default User Policy – Secure” had all the correct settings as this was the biggest policy to be migrated.
- Now, just to show that all of this has worked from a configuration side, I can sign into the StoreFront site created in my previous blog when we deployed a XenApp 7.x POC using the blueprint in CLM.
As you can see, the applications with correct icons are listed. However, at present there is no VDA to log into that host the applications.
And there you have it! A migrated XenApp 6.5 to XenApp 7.x environment… Or is it!?! Well, we have all the settings but no Worker/VDA to log on to and run our applications from!
Well, tune it for Part 3 where I will customise an existing Blueprint to install and configure the XenApp Virtual Desktop Agent (VDA) onto an existing XenApp 6.5 Worker server to show how you can fully migrate from XenApp 6.5 to XenApp 7.x with Citrix Lifecycle Management.
As always, thank you ever so much for reading this article.