Citrix Cloud: Part 4 – Using Citrix Lifecycle Management Smart Scale to intelligently control your cloud-hosted workloads!

Hello and welcome to Part 4 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.

Recap…

In Parts 1, 2 and 3, we used Lifecycle Management to migrate our XenApp 6.5 to a newly deployed XenApp 7.x environment, complete with configuration, policies and applications. In my case, the new XenApp 7.x environment was in Azure.

In this part, we will look at how you can control the biggest cost factor when utilising a public cloud, such as Azure or AWS, to deploy your XenApp/XenDesktop workload.

Background

As I mentioned above, the biggest cost involved when using Public Clouds is compute costs. The more CPU, memory and disk you want, the more you pay. It’s also the beauty of it. So, let’s take the following example:

After looking at this whitepaper on XenApp 7.11 scalability in Azure, we’ve decided to deploy the D2v2 instances to be our VDAs.

These have a cost of £0.1491 per hour or approximately £110.90 per month, per instance when deployed into the Northern Europe Azure datacentre.

According to LoginVSI, we’re looking at around 15 users per D2v2 instance before performance drops off.

If we wanted to supply published resources for 1000 users, we would then require approx. 67 D2v2 instances, which would have a monthly cost of £7430.30 which sounds like a lot! You could also say that this is £7.43 per user per month which doesn’t sound so bad. However, there are other related costs such as storage and outbound bandwidth used + the licensing to factor in.

But, would you really need 67 instances? And if you did need to cater for all 1000 users at any point, would all of your 1000 users work 24/7? The answer is probably not. Even if you had peaks during the day (or night) where all 1000 users required their published resources, this would probably not be maintained 24/7.

If a user required their resources for 12 hours a day, which still would probably be an over-estimate, then, if you could turn off resources which aren’t needed, you’ve potentially cut your costs from £7430.30 per month to £3715.15 per month or £3.72 per user per month. Wunderbar!

Now, of course these are hypothetical calculations but you can see how you could easily save a lot in Cloud running costs if you can control when your instances are running.

Welcome Smart Scale!

So, with Smart Scale which is a component of Lifecycle Management you can! Using the same Lifecycle Management Agent on your endpoints (VDAs in this instance), you can set up policies to control when you VDAs are powered up and powered down based on either:

a schedule; say 9am – 5pm
workload; when either x amount of users are logged on per server or when the load evaluator reaches 10000
or a mixture of both

How does it work?

For schedule-based policies, by talking to your XenApp/XenDesktop Controller, the VDA will be placed into maintenance mode at the allotted time to stop any further connections. Once all connections are off, the server will be shut down. Likewise, when it is time, the server will start up and be made available for user connections.

For workload based policies, if you reach either reach the designated number of users per server, or a reading of 10000 on your load evaluator, another server will be powered on to increase your capacity. Likewise, as users log off and servers become empty, these servers can be shutdown.

In order to make sure you have VDAs available, you’re able to set a minimum number of VDAs to leave on. So, you may wish to have 10 VDAs available at anyone time knowing that you can instantly server ~150 users (based on our example above).

Show me the Smart Scale!

Ok, enough talking, let’s see it in action! In my example below, I have configured Smart Scale to use both a schedule and server load.

Considerations

There are some considerations when using Smart Scale that I found during my testing:

If users are active on a server, they will not be logged off and the server will not be shut down. In order to control this, I would recommend putting in some type of timeout for idle and disconnected sessions.
If using the Load Evaluator index as your metric, you need to set a policy for this within either Studio Policies or Citrix Policies GPO, otherwise it uses the default of 250 users for a full load. I configured mine for 85% CPU and memory to show the server as Full Load.
It takes a few minutes to pick up changes in workload/user count so take this into your calculations when setting policies – don’t make them too tight otherwise you may not spin up resources fast enough.

Let’s Go!

From your Citrix Cloud login, select Smart Scale (new tab on the RHS)
You will now see the XenApp and XenDesktops Sites that have been registered with Citrix Cloud. This is automatically done for you when you use the Blueprints to deploy a XenApp/XenDesktop environment, whether that be on-prem or in the Cloud. The Site I created during Part 1 is CtxInAzure. Click View Site.
You will now see the Delivery Groups within your XenApp/XenDesktop Site and the state of Smart Scale. In my case, I have an Azure – North Europe DG with Smart Scale disabled.
If you scroll down on the Monitoring page you will get stats such as Estimated Savings (none so far), current sessions and the Load Index. You can also filter these by 2, 4 or 24 hours and the past 7 days.As you can see here, I’ve loaded my 2 VDAs with 4 users. Due to the DEFAULT load evaluator of 250 users per server, the load index is very low and only 80 (max = 10000). As general guidance I would recommend setting your own load evaluator policy based on your environment requirements, which I will be doing shortly.
At the top of the Smart Scale screen, I’ve clicked on Configure. You’ll now see your options. By default Load-based and schedule-based scaling is selected. I will be using this option.
You’ll see at the bottom, there is an option to set (in US $) the amount per hour of your VMs in the cloud will cost. I’ve amended it from the default $0.06 to $0.113 as I will be running Azure A2 instances for my VDAs. You can find a price list of Windows VMs in Azure here.
I then changed the Scale Metric to Load Index (defaults to Session Count).
To configure my own schedule, from the Schedules section I’ve clicked Create New. This will allow me to set when my machines will power on/off and how many machines I want on as a minimum.
I’ve given my schedule a name of Office Hours with a Min # of Machines On as 1. Just to reiterate, this is the minimum amount of VMs that WILL ALWAYS be powered on. In a Public Cloud scenario this will have a cost implication so plan accordingly!I then set my hours as 8am – 6pm all workdays (Mon – Fri). I’ve then clicked Create.
I now have my own defined capacity and power management policy, based on my environment and pricing so hopefully it should give me the best value as well as the best user experience! Livin’ the dream, eh?
You’ll see that by default, Smart Scale is disabled.
Click the button to enable Smart Scale!
Now click Return to Site Details to see the magic! 🙂
You’ll now see that we will start gathering data on $$$ saved. Over time this data will build and you’ll be able to sit back in your own glory on how you’ve made cloud workloads cost effective!
By hey? What’s happened here? I have a machine in maintenance mode! This is because we’re outside of Office Hours so its placed a VDA in maintenance mode. Now, what I came across was as I had users logged in, then the server stayed up. However, as soon as I logged the users off of the VDA in maintenance mode Smart Scale kicked in the next part… So another recommendation here is to set a policy for Session Idle and Disconnect timeouts.
If you click on the Events tab (next to the Monitoring tab), you’ll see that there’s an event to power off 1 server.
Clicking on the Machine Activity, you’ll see that CTX-XA-01 was powered off and the start/end time of the action.
If I look in Studio, I will see that indeed my VDA is off.
So that I actually believe I’m not being billed for this VM any more, I’ve gone into my Azure subscription and voila! The VM is Stopped (deallocated) which means I am no longer getting billed for compute costs (the higher costs of running VMs in public clouds). However, please be aware there is still a storage cost involved with having this VM provisioned, it’s just a lot smaller than the compute costs.
The next piece of the puzzle was how to get this machine to come back on when it is required – i.e. when the existing powered on servers have reached (or better still are reaching) capacity? Learnt through T&E (trial & error), I found that Smart Scale just uses the load evaluator settings from the Site, which seems logical but I just wanted to make you aware that it doesn’t use anything in Smart Scale per se, you still need to configure a policy based on your needs.I’ve created a simple policy called “Load Management Policy” setting max load when CPU and/or memory reaches 85%. I’ve applied this to my Azure – North Europe Delivery Group. You will need to reboot the VDAs to pick up the setting.
Now, I’ve logged onto my published Azure Desktop as a test user and generated CPU load by using CPU Stress tool and a memory leak by using Testlimit from SysInternals. Task Manager shows us what’s happening.
If we switch back to Smart Scale Monitor screen, we see that we have 4 users logged in (you can see the dip where I rebooted the server :-p) and after a few minutes, the load showing as 9845, so very nearly maxed out.Something I forgot to mention was that there is a buffer (default to 10%) of the thresholds set. So, in my case, once the load index reaches 10000 – 10% = 9000, it will trigger the magic!
If the top of the Smart Scale window, if we click on the Events tab, we see that there is an event triggered to power on a server.
Clicking on the Machine Activity tab, we can see that CTX-XA-01 is powering on!
If we flip over to my Azure Subscription, we can see that the VM that was off, is now on! Hazaar!
Back over in Smart Scale, we now see that there are 2 machines on.
Looking further down, we see that we still have 4 sessions but the load index has dropped as we have double the resource available.
What I did next was to stop CPU Stress and TestLimit to drop the overall load. I also haven’t logged in any additional users to the newly powered on VDA. After a few minutes, you see the load drop down.
If I click on Machine Activity, you’ll see that the CTX-XA-01 which had powered on to be ready for additional capacity is now powering off.
And after a few minutes you’ll see that the VM has been Stopped (deallocated) meaning I’m no longer getting billed for the compute for this VM.
Again, in the Monitor tab of Smart Scale you can see that we now only have 1 machine running and our load index has decreased further.

Conclusion

So, I hope you’ve seen the power of Smart Scale and how, through this configuration, you can really help drive value for your cloud-based workloads by configuring the policy to your environment needs. This could be the difference between moving workloads to the cloud or not, so I think it has massive potential.

Here we used just 2 servers, but imagine our example from above of 67 servers and the cost savings per month you could achieve here.

Smart Scale is just one part of the Citrix Cloud offering and a tool of Lifecycle Management. Though these series of blog articles I’m trying to showcase these so that everyone can see the power of the Cloud and how Citrix is at the forefront of Cloud technologies and we take this very seriously and want to provide our customers with the tools to make their move to the cloud, however small or large, a success to help drive better value for their business.

Stay tuned for further Citrix Cloud articles and thank you for reading!

Citrix Cloud: Part 3 – Using Citrix Lifecycle Management to “complete” our migration from XenApp 6.5 to XenApp 7.x

Hello and welcome to Part 3 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.

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 5 – using Citrix Lifecycle Management to Upgrade your XenApp 7.x Site to the latest version.

Recap…

In Part 1, we looked at using Citrix Cloud Blueprints to deploy a small scale (POC) XenApp environment into Microsoft Azure. With Part 2 we used the Migrate service of Citrix Lifecycle Management to migrate all of our applications and policy configuration from our XenApp 6.5 Farm to our newly deployed XenApp 7.x Site.

In this part, we will look at a customised Blueprint to install the VDA onto our XenApp 6.5 Worker Server that will then automatically remove XenApp 6.5 and configure access to the new XenApp 7.x Site. The reason for doing this is to “finalise” our migration so that we now have a XenApp 7.x VDA with our existing applications installed.

Why?

Why would we want to install a VDA onto our existing XenApp 6.5 Worker Server you ask? Why not build fresh you say? Well, although this isn’t an exhaustive list, here are a few reasons why you may wish to use an existing XenApp 6.5 Worker (APP) Server…

This gives you a quick way to get your existing applications into your XenApp 7.x environment and into UAT (User Acceptance Testing) without any repacking/redeployment (my use case)
You may have complex applications that you do not wish to spend time redeploying and/or no longer have the skills/knowledge/instructions in house any more (i’ve come across this too many times!)
Applications may be farmed out to a 3rd party and they will charge to redeploy these to a new image
You may not have the time to redeploy these and/or you do not have the applications packaged or a centralised deployment tool such as Microsoft System Centre Configuration Manager
You need to deploy existing applications very quickly to your new XenApp 7.x Site due to business pressures such as a new acquisition.

As you can see, there are plenty of reasons why you may wish to do this and I bet you can come up with a few of your own!

Using this method would also mean minimal change for the users. Your users will now be going to StoreFront instead of Web Interface but their applications and desktops will be there waiting for them, giving them comfort within the familiar (never underestimate this factor!)

My vision of “The Future”

I also see this as part of the “larger” migration strategy using Citrix Lifecycle Management which will hopefully come to fruition once Azure ARM support is added (P.S. it’s on the way, currently in test 😉 Privileges of being on the inside!)

In the very near future, I would like to see a “complete” automated migration process that would look something like this:

Similar to Step 1, we deploy a XenApp 7.x Site in the cloud of our choice which is production ready, i.e. 2x StoreFront, 2x Delivery Controllers, license server(s) etc.
Using Citrix Lifecycle Management Migrate feature, we take all of our settings from our XenApp 6.5 Farm and migrate them into our XenApp 7.x Site
We deploy our VDA (configured to connect to our new Delivery Controllers) to a number of Workers from the old farm – this could be an instance of each silo type if using silos or just a single worker if you have a common image
Using the Hosting Connectors within Studio, we now use this/these as our template server(s) and deploy our Machine Catalogs and Delivery Groups using Machine Creation Services (MCS Azure ARM support was released with XenApp/XenDesktop 7.11) or if supported, Provisioning Services
With absolutely minimum effort and probably the fastest time to value, UAT can begin!

The possibilities here are endless with potential interaction with Citrix AppDNA for automated image and application validation and even application packaging with App-V! These could be done with scripts and I see no reason why not in future releases! Please note that as far as I’m aware, these are not upcoming features but my dreams. However, I’ll mention it to the Citrix Cloud team and let you know what they say 😉

So… what’s the value of Cloud you ask? Stop thinking “VM’s in someone else’s datacentre and think of automated, wizard driven services enabling quicker time to faster, faster ROI, lower TCO that are tried, tested, consistent and repeatable! No more hours of manual hardship, guessing and fingers in the air but predictive results based on your data and use cases! THIS IS THE POWER OF THE CLOUD MY FRIEND!

The Business!

So, sometime, long ago, I mentioned something about using a customised Blueprint to deploy a VDA and get our legacy XenApp 6.5 application Worker Server into our new and shiny XenApp 7.x Site, right? ;-p

To skip forward a few steps, I created my own Blueprint but using an existing blueprint, copying it and removing all of the processes except that used for installing the XenApp/XenDesktop 7.x VDA.
As I knew I was installing onto an existing Citrix Worker Server, I also removed installing .NET as this would have already been done and removed installing Remote Desktop Services and all the ancillary features such as Desktop Experience etc.
This did take a bit of trial and error and perhaps a blog post for another day! We will see the steps of deploying the VDA in more detail shortly so hopefully you’ll see what I did to get there.
I also had to change a few of the blueprint parameters to show the Delivery Controllers and Domain options.
So, using my customised Blueprint “Install VDA” I selected it and chose Deploy.
As you can see, I’ve given my blueprint a description. Click Start deployment setup.
You get a default value for the Deployment Name. I’ve left this and clicked Next.
Select a resource location. As usual, I’ve selected my Azure Subscription but this could be any one of the supported Resource Locations. Click Next.
There is nothing to configure on the Scale tab, so I clicked Next.
I now need to pick a server to deploy the blueprint to. Following the same steps (18 – 20) from the previous blog, I installed the Lifecycle Management Agent onto my Worker Server so that it was available to deploy to this server. I selected CTX-XA-01 and then clicked Next.
You now have the Pre-deployment check list. You can export a parameters .csv to import later but as we only have a few variables, I’ve skipped this. Click Continue.
Now I need to fill in my required parameters. In this instance, that is Domain Name, Administrator Account, Password and importantly Controller(s). You will notice I’ve put in the name of the Delivery Controller deployed via the POC blueprint in Part 1. Then click Next.
You can now save the configuration as a Profile, in case you wish to use it again. By doing this, if your blueprint fails or you wish to deploy it to another server, you can select you Profile at the start and save the time of entering the various parameters. Click Save.
You will now see a summary. If this is ok, click Deploy.
The blueprint now deploys. First, Autoadminlogon is set. This is needed to pass the admin credentials you entered in earlier.
Then 7-Zip is installed (downloaded via the Blueprint). This is required to unpack the XenDesktop/XenApp ISO.
The XenApp/XenDesktop 7.9 ISO is then downloaded.
And now expanded via 7-Zip.
Via a PowerShell script with the various parameters we entered in Step 9 earlier, the VDA is now installed. As part of this installation, XenApp 6.5 will be uninstalled and the server removed from the xenApp 6.5 farm gracefully.
After that, assuming all goes through, autoadmins are disabled and the VM is rebooted.
With the blueprint completed successfully, everything is Green! You can also revisit and wallow in your marvellousness by clicking on Get Deployment Report.
Now, to confirm that the VDA installed successfully, firstly I logged into my XenApp 6.5 Zone Data Collector and checked the server list. No sign of my worker, CTX-XA-01. So far, so good!
Next, I logged onto CTX-XA-01 and looked in Programs and Features. There’s still a few bits left over but XenApp 6.5 but most of the components have been removed and low and behold there is a VDA 7.9!
Next I logged into my Delivery Controller and created a new Machine Catalog.
At the Introduction window I’ve clicked Next.
I’ve selected Server OS and clicked Next.
For the Machine Management, as I hadn’t configured any Connectors for Azure, I’ve select “Machines that are not power managed” and “Another service or technology”. Click Next.
I’ve now browsed Active Directory and added CTX-XA-01 and then click Next.
And there we have it, a Machine Catalog with my newly migrated VDA!
Next, using the already deployed Delivery Group created during the Migration process (XenApp65), I’ve selected Add Machines.
I’ve now added our new VDA from the XenApp 65 Catalog and clicked Next.
And then Finish.
As we saw in Post 2, if we log into StoreFront we will see our newly migrated applications from the XenApp 6.5 farm. However, if we click to launch an application we should now have a resource in the background to provide the application…
And voila! Our published application, previously available in our XenApp 6.5 Farm is now fully migrated to our XenApp 7.x Site! And all using Citrix Lifecycle Management!

Summary

So, to summarise, using Citrix Lifecycle Management thus far (and no other tools), we have:

Created a new XenApp 7.x deployment in Azure
Migrated our XenApp 6.5 Farm settings to our Azure XenApp 7.x Site
Used a customised blueprint to install the XenApp 7.x VDA and remove XenApp 6.5
Added the new VDA into a Machine Catalog and Delivery Group via Citrix Studio
Launched our published application from our new XenApp 7.x.

So, I hope I’ve shown you the power of Citrix Lifecycle Management and how with a bit of knowledge and not much trouble, you can migrate from XenApp 6.5 to XenApp 7.x with minimal fuss. Now I appreciate this was a POC with only a few applications but you can see the process and that there is no reason why it wouldn’t work for a full scale production based on an on-premises XenServer or AWS deployment as well.

I’m also aware that the steps of adding the VDA into a Machine Catalog and Delivery Group could be fully automated via a customised PowerShell script for full end-to-end automation, so if you wish to do this, then please be my guest.

I will be adding more to my Citrix Cloud series in the coming weeks as we are far from over but I really wanted to show you that Citrix truly sees Cloud as their future and isn’t just saying this, but is delivering on it.

Going back to a few of my earlier points I wanted to highlight a few things:

Citrix Lifecycle Management at present does not support Azure ARM and currently only Classic mode which means you cannot integrate this process with the newly released MCS Azure ARM support – yet. The good news is that support for Azure ARM deployments is coming!
I understand that I didn’t show you the process of making the VDA blueprint, however, I am hoping that Citrix will officially release one as I’m talking to the Citrix Lifecycle Management team about the possibility – for the reasons listed above. Fingers crossed!
You do require knowledge of XenApp/XenDesktop and a familiarity with Citrix Cloud and Lifecycle Management. For those who may be reading this article, like what they see and wish to use these methods but are worried that they do not have the skills, then I recommend that you either speak to your Citrix Partner who will be able to assist you in trialling/testing/deploying using Citrix Cloud or if you deal direct, speak to your friendly SE (if you deal direct you will have one!) who can help you on your first steps to Citrix Cloud!

Thank you again for reading and please look out for future Citrix Cloud posts from me!

Citrix Cloud: Part 1 – Using Blueprints to deploy a XenApp/XenDesktop 7.x Site

Hello and welcome to Part 1 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.

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 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 4 – using Citrix Lifecycle Management to Upgrade your XenApp 7.x Site to the latest version.

Part 5 – 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 will look at using Citrix Cloud Blueprints to deploy a small scale (POC) XenApp environment into Microsoft Azure. I am using Microsoft Azure as this is my lab environment but it could be AWS or another public cloud or any on-premises, co-hosted or any datacentre that is running Citrix XenServer, Microsoft Hyper-V or VMware ESXi. It really doesn’t matter. At Citrix we believe in giving you as much choice as possible and allowing you to work with what you have.

Blueprints allow you to deploy a best practice XenApp/XenDesktop environment onto your chosen platform with the minimum of setup. Using scripts and workflows, the relevent servers and services are deployed automatically. Citrix have published a few best practice and small-scale deployments along with some community and partner blueprints. Blueprints are found in the Blueprint Catalog.

The blueprint we are using in this example is the Simple XenApp and XenDesktop Proof of Concept blueprint that will deploy a standalone Domain Controller, XenApp Controller, VDA and NetScaler VPX. All Windows Servers are based on Windows Server 2012 R2. Let’s see how we do it!

Log into your Citrix Cloud account at citrix.cloud.com. If you don’t have an account, you can sign up for a free trial and request Lifecycle Management. If you do need to sign up for a free trial, it shouldn’t take too long to provision for the Lifecycle Management side. However, I understand that for other sections, trials are very sort after and space is limited so trials for the XenApp & XenDesktop Service may take a long time to come through. For this and the next few “exercises”, you will only need Citrix Lifecycle Management.
Navigate to Lifecycle Management and click Manage.
Select Blueprint Catalog.
In this example, I selected “Simple XenApp and XenDesktop Proof of Concept”. Feel free to look at the other available blueprints, such as the production ready “XenApp and XenDesktop with SQL” blueprint.
Click Add to Library.
Now you will need to add a Resource, which is essentially your datacentre where you’ll be deploying stuff. Click on Resources and Settings.
Click Add Resource Location. Select the appropriate location type. In my example, I selected Microsoft Azure.
You will now need to provide your Azure details to finalise the connection. Once connected, you will see your location listed.
Now that you have a Resource Location, click on Design and Deploy. From the drop down menu on the blueprint, select Deploy. This will start the deployment wizard.
Select the name of your deployment. I have gone with the default. Click Next.
Select your Resource Location, in this instance my Azure Subscription I added in a previous step. Click Next.
You’ll now get the pre-reqs list which you should read through. There’s also the option of exporting a parameter list csv file that you can amend and upload later but for the sake of this example, I am carrying out the steps manually. Click Continue once ready.
You’ll now see the list of components that will be deployed as part of this blueprint. There are; Domain Controller, XenDesktop Delivery Controller, Server VDA and NetScaler VPX. Click Next.
You now create the virtual machines configuration. Select Create new VMs and for the Domain Controller, from the dropdown menu, select your Resource Location.
For the Azure deployment, you now select which OS you want to use, in my case Windows Server 2012 R2 Datacenter and which variant of this. I choose the most recent build of August 2016. Click Select on your image.
Also, I had previously configured some of the backend Azure requirements such as the Virtual Network, Subnet, Cloud Service and Storage Account.
As of time of writing, only the Azure Classic infrastructure is supported so make sure you bear this in mind and provision accordingly. I have decided that the provisioning of these is outside of the scope of this article. Also, it may be that Azure isn’t relevant to you. I will try to cover an on-premises deployment via Citrix XenServer at a later data.As I only had a single Classic VNET, a single Subnet, a single Cloud Service and Storage Account, they were automatically selected. If you don’t already have any of the Classic Azure components, you can create them through the wizard though. I found it to be simple and self explanatory (providing you are familiar with these Azure concepts). Once done, click Next.
You now need to create an account and password. I’m not sure if this is a pure Azure only option due to the way machines are configured, so mileage may vary! Enter in the required details and click Next.
You are now on the Summary page. This also gives you the awesome option to configure your other virtual machines with the same configuration which is a great time saver. If you wish to do this, make sure “Copy this configuration to other VM tiers”, “XenDesktop Delivery Controller” and “Server VDA” options are ticked. Click Finish.
Review that all the information is correct and click Next.
You now have to enter the name for your domain and the SafeMode Password, XenDesktop Site Name as well as some other information. All passwords are encrypted. Something else which is a bit of a PITA for a demo/trial is the NetScaler license. Since a recent change, you can no longer move on without it so you will need to get hold a NetScaler license.However, I was confused on this as getting a NetScaler trial license is easy, however it is tied to the MAC address of the appliance, which you don’t know as you haven’t deployed it so it’s a bit chicken and egg. I managed to get hold of a platform license and hope that this is enough. I will update once I have more information.Once you are happy, click Deploy.
You will now see the Deploying “wheel of destiny!” In all likelihood, this will take a few hours to run through.
You’ll be taken to the progress page which shows all the steps.
Now, my deployment didn’t quite complete, and I’m currently investigating this as it failed at the NetScaler configuration but all components were created including the VPX and configured without issue. Here’s a view from within Azure.
We can now log into the Delivery Controller and see what’s what within Citrix Studio. I did this by connecting to xd-poc-xdc. As we have installed a POC and the Controller and StoreFront roles are together, you can see the StoreFront management nodes at the bottom.
As you can see, a machine catalog has been created and the VM “VDA” added.
Also a Delivery Group was created and published desktop. As part of the POC blueprint, a published desktop is automatically created.
To spice it up, I’ve published some critical LOB applications 🙂 These were added in exactly the same way you would do in any other deployment of XenApp with Studio.
Going down to the StoreFront node, you can see that the Store and StoreWeb sites have been created.
Now, from the Domain Controller that was created, I opened IE and navigated to http://xdc.cloud.lab and low and behold I was presented with StoreFront and it asking me to install Citrix Receiver!
Once I installed Receiver, I was able to continue and log in. By default, the Domain Users group of the domain created as part of the blueprint has access to the pre-created Delivery Group so nothing more than your original administrator or a test user in Active Directory would be required.
Navigating to the Apps tab shows all of the applications that I published!
Moving to the Desktops tab shows the “Sample Desktop” published as part of the POC blueprint.
To prove it works, I launched NotePad successfully! A throwback from my consulting days. If I can launch NotePad, I can launch anything :-p Project completed!!!
Curiosity got the better of me so I launched the published desktop as well!

So, there you have it. Using Citrix Lifecycle Management and the built-in blueprints, we’ve been able to deploy a XenApp 7.9 POC environment in Azure. Please bear in mind that there should also be a NetScaler Gateway in the mix here and I will report back and update the blog once I have this fixed so you would also have external access.

It is also worth noting that this deployment could have been on Amazon Web Services (AWS), Citrix XenServer, Microsoft Hyper-V or VMware ESX. We could have also deployed a full scale production-ready XenApp environment consisting of 2x Delivery Controllers, 2x StoreFront servers, 2x Provisioning Servers, 1x License Server and a mirrored SQL environment (3x VMs) to house the databases. There are also blueprints to deploy NetScaler VPXs in their own right so you have the possibility to use CLM to deploy an end-to-end XenApp environment.

I’ll wrap up this article here but please stay tuned for further articles on Citrix Cloud and Lifecycle Management. In Part 2 I hope to show how to automate the migration from a legacy XenApp 6.5 Farm to this newly deployed XenApp 7.9 Site.

Thanks for reading!