By Paul Wilson
Is your XenDesktop Hosted-shared desktop (XenApp) farm in the Cloud? Have you thought about putting it there? If it only took a few hours to create a XenApp farm in the cloud, would you consider cloud service delivery for your apps and desktops?
In case you are new to Amazon Web Services (AWS), you should know that Citrix has recently released a whitepaper and a CloudFormation template also stored on AWS S3 that can get you up and running with your very own XenApp farm in as little as three hours. This CloudFormation template uses publicly available Amazon Machine Images (AMIs) and snapshots to build a basic farm in an AWS Virtual Private Cloud (VPC). In this way, you can jumpstart a move to cloud delivery. Of course, you need to bring a few things along, like XenDesktop licenses and your applications.
When using the CloudFormation script in its default configuration, a basic XenApp farm will be created in the AWS US-East availability zone, which costs approximately $3.25/hour to run. The diagram and table below provide an overview of the components of this XenApp farm.
|Host [Internal IP]||Role||Notes|
|Bastion [10.0.0.6]||Provides access to private network||Bastion works like a jump box allowing RDP access through the assigned Elastic IP address|
|Access Gateway (AG) VPX [10.0.0.170]||Provides remote access to applications hosted on the private network||Uses an Elastic IP address for external access and points to the internal Web Interface site|
|NAT iNet Gateway||Provides Internet access to all of the hosts on the private network||Uses an Elastic IP address for all outbound Internet traffic|
|AD Domain Controller [10.0.1.5]||Provides authentication and authorization services as well as DNS services to the private and public subnets||This is set up as a new domain in a new forest using the supplied domain name when the instance is created|
|XenApp [10.0.1.6]XenApp-BDC [10.0.1.7]||Provides data collector and XML services for the farm and the Web interface queries||Two hosts are configured for fault-tolerance. Use these to administer the farm|
|Web Interface [10.0.1.8]||Provides Web interface sites for internal and external access||http://xenapp-wi/Citrix/InternalXenApp (Internal XenApp)http://xenapp-wi/Citrix/XenApp (Access Gateway)|
|Install Server [10.0.1.9]||Provides the XenApp 6.5 installation media and hosts the execution of the PowerShell scripts that build the farm||Can also be leveraged as a file server for roaming profiles|
|Worker Servers [DHCP]||Worker servers take user connections and host the published applications||The default worker server AMI has no applications installed. All worker servers will receive random names and DHCP assigned IP addresses in the range of 10.0.1.10 to 10.0.1.254|
What you need
For the CloudFormation template to finish successfully, you will need the following:
- Amazon AWS account (http://aws.amazon.com)
- At least three available Elastic IP addresses (Amazon limits each account to 5) for the NAT, AG, and Bastion host
- At least ten available instances (Amazon limits each account to 20)
To actually connect to applications remotely, you will also need the following:
- Citrix XenApp or XenDesktop Licenses (demo licenses are available through your MyCitrix account)
- Microsoft RDS Licenses (if you want to go beyond the trial period)
- Domain Name and SSL certificate for the AG
Using the Template
This blog gives an overview of the steps required to use the CloudFormation template and build the XenApp farm — adventurous users can attempt the procedure on their own. Otherwise, the whitepaper contains step-by-step instructions. The setup process includes these general steps:
- Login to the AWS Console.
- Select the CloudFormation tab.
- Choose Create a New Stack.
- Provide the name of the stack and the location of the CloudFormation template , or upload a copy of the template.
- Complete the parameters section of the template and the remaining wizard steps.
Note: The number of worker servers represents the number of servers that will always be running. Even if you shut these servers down, AWS will restart them.
- Wait 30 minutes for the instance creation to finish.
Building the Farm
At this point, all of the instances in the figure above have been completely built. The NAT iNet Gateway, AD Domain Controller, Install Server, and Bastion host are completely configured. (Not bad — you’re 40% through the process after just 30 minutes.) Once instances have been created, the next step is to configure the XenApp components, including the XenApp data collectors, Web Interface, and Worker servers. To do this, you connect remotely to the Bastion host. From there, you use the RDP client to connect to the Install Server (10.0.1.9) to complete the following steps:
- Open a PowerShell prompt.
- Change directory to C:\Program Files (x86)\citrix\App Delivery Setup Tools.
- Execute the template .\AWS-Farm-Build.ps1.
- Answer a few configuration questions and type YES.
- Wait about 2 hours.
Should this process fail, you can try troubleshooting, or in most cases, it is faster to just delete the AWS stack and start over. The scripts are fairly robust and provide useful troubleshooting messages. If nothing goes wrong (sometime errors might occur due to timeouts, not unexpected on a public cloud), all the XenApp servers are installed and joined to the farm, and the Web Interface server and Licensing roles are installed. This means the farm is 90% configured with only licensing, publishing applications, and Access Gateway components left to complete.
Licensing and Administration Tasks
To configure licensing and publish applications, use the Bastion host to RDP to 10.0.1.6, the XenApp Data Collector. The role manager wizard starts automatically and you need to configure the licensing service for the server. It is probably best also to launch AppCenter and configure a policy to set the license server to 10.0.1.6 for all farm servers. At this point, you can publish applications to the worker group and test access by going to the site http://xenapp-wi.domain.com/Citrix/InternalXenApp from one of the XenApp servers.
Configuring Remote Access
The Access Gateway AMI is an existing AMI that we are reusing for this configuration. As such, the appliance must be configured to point to our cloud resources. You can connect to the admin console (using the credentials admin/admin) by going to https://10.0.0.170/lp/adminlogonpoint from an internal host (such as the Bastion host or the external interface via the Elastic IP address instead of 10.0.0.170 in the previous URL). Once connected, update the following sections:
- Secure Ticket Authority – Delete the existing one and add the FQDNs of XenApp.domain.com and XenApp-BDC.domain.com on port 8080.
- XenApp or XenDesktop – Set the range of IPs to be x.x.x.5 – x.x.x.254 and enable Session Reliability protocol.
- Logon Points – Point the Web Interface site to http://xenapp-wi.domain.com/Citrix/XenApp.
- Licensing – Provide a valid license file. Without it, connections through the Access Gateway will fail.
- Admin Password – Please change the admin password immediately. Failure to do so leaves open an entry point that can that can result in a security breach.
- Name Service Providers – Update the DNS name servers if the VPC subnet IP addressing scheme was changed from the default.
- Networking – Update the networking IP address and default gateway if the VPC subnet IP addressing scheme was changed from the default.
- Certificates – Add a valid SSL certificate to the AG appliance.
- Reboot the Access Gateway.
Once the configuration tasks are complete, you should be able to successfully connect to the Elastic IP address assigned to the Access Gateway and launch an application.
Wrapping it up
Should you wish to watch these steps in action, follow the video blog available on CitrixTV, which we are in the process of editing. We’ll update this blog with the Citrix TV URL when we’ve finished.
Now you have a new XenApp farm in the cloud. Take advantage of it for:
- Application Testing
- Business Continuity
- Testing XenApp performance in the cloud
- Learning how to manage AWS resources
Comments and feedback about the CloudFormation template are most welcome. In future blog articles, I’ll discuss how to create your own AMI images to use with the CloudFormation template as well as a little more about some of the secret sauce that we used that makes this possible. Also, as the CloudFormation template evolves, I’ll post new versions.