A few months’ ago, I wrote a blog post discussing the architecture of a Citrix Cloud solution that leverages NetScaler’s Azure VPN capabilities. This solution was limited to Azure Classic mode, which, up until July 4th, was the only supported native provisioning method for Azure.
But there’s good news! We now have Azure Resource Manager (ARM) as an option for native provisioning. This is a fantastic addition, since this mode is the direction in which Microsoft is moving.
And what is the first Citrix product to allow for native ARM integration? Citrix Cloud XenApp and XenDesktop service. (To remain consistent with the portal, it will be labeled as just “Microsoft Azure” in our hypervisor drop down list.)
Prasanna first announced this integration in this blog post.
Alex published a great blog post recently that took a deeper view into the science behind our Azure Resource Manager integration. My post today will focus on the setup and delivery of your desktops and applications.
In this example, I have setup a VPN connection from my on-premise NetScaler to the Azure West datacenter.
This VPN configuration allows me to access on premise company resources from my Azure-provisioned workloads. Additionally, I can also now have all my Azure resources domain joined. Be aware, however, that when it comes to providing Active Directory services in a cloud resource zone, you actually have three options;
- Domain joining all Azure resources to your on-premise domain.
- Deploy a domain controller in Azure as a separate AD site for your on-premise domain.
- Deploy a completely separate Active Directory in Azure, and establish a trust with your on-premise domain.
Here are the configuration details of my Gateway and lab setup:
- I am running NetScaler 11.0.66.11.nc for my Cloud Connector appliance.
- My Azure VNET is 10.100.0.0/16.
- My on-premise network is 192.168.89.0/24.
- I created a bastion or jump server in Azure to perform my configuration work. This server has a public IP and the port for RDP (3389) was open via a single Network Security Group. It is placed in the subnet of 10.100.1.0/24
- All machines were created in the US West region with the “Resource Manager” method via the web portal.
- The server that has the Cloud Connector and the VDA installed are part of the 10.100.2.0 subnet.
- I have a Citrix Cloud account with 3 resource locations; 1 for my on-premise, 1 for Azure Classic (Central) and 1 for Azure ARM (West).
- All resources in Azure are domain joined thanks to the VPN connection.
- All resource zone servers are secured by leveraging Network Security groups (NSGs) within Azure
- I used the GUI for everything, and did not use PowerShell or the NetScaler CLI. The GUI for a CloudBridge Connection to Azure is simple once Azure supplies you the Public IP to use for your connection. The GUI screenshots can be found at the bottom of this Citrix document.
- This Microsoft Azure article was the main reference point to verify that my address space and Azure configuration was correct.
Once the VPN in Azure was configured, configuring my local ports and running through the NetScaler Azure wizard was quick and easy. The layout shown below is the same as before. We happen to be connecting to an Azure datacenter in the West, rather than the only US “classic” data center in the Central.
The Connector in Citrix Cloud:
When using Cloud Connectors to access a resource zone, a minimum of two Cloud Connectors are recommended. Mine are configured as follows;
The “Azure ARM – West” zone was created prior to the install of the Cloud Connector. Then I created a low cost Basic A1 instance in my Azure Region. This computer will be used as the Cloud Connector for this zone. You can find a list of instances and their monthly estimated cost here.
During the Cloud Connector install you are prompted for your Citrix Online user credentials for Citrix Cloud. After a successful authentication, you are asked to select your location. This must be created prior to installation because you cannot create one from the installer. Chose the appropriate resource location for your environment.
A quick note about Azure Availability Sets. As a recommended best practice, leverage Availability Sets for your deployments. This spreads your computer load across fault and update domains to limit you downtime and provide the 99.95% SLA that Azure stands by. For more information on Availability Sets, please click here.
Create your zone first in Studio:
Before moving forward. Make sure you have created a new Azure zone in Studio and place the correct Azure Resource Zone Cloud Connectors into that zone. To avoid host creation errors, make sure at least one of the Cloud Connectors is powered on and accessible.
The creation of the Hosting location:
Right click on the Hosting node and create a new Host Connection. When you first add a new connection, you will see additional drop options.
The initial setup for Azure Resource Manager and Azure Classic varies slightly. With Azure Classic, we simply imported a publishing file and away we went. Azure Resource Manager is different; it needs to create a Service Principal. Overviews of Service Principals and ARM can be found here and here, respectively. To draw a short quote from the last linked article:
“When you have an automated process or application that needs to access or modify resources, you must set up an Active Directory application and assign the required permissions to it”
Since we are going to leverage MCS for our provisioning method and create resource groups along the way, the need for the Service Principal comes into play.
First things first: we need our subscription ID. Copying this into the console is a two-step process. First, copy it to your clipboard on your local machine. Second, select the clipboard icon on the HTML5 client bar and paste your information into the window. This can now be pasted into the subscription ID field.
The zone name entered during a previous step will be available to you when you click the drop down arrow. Select the appropriate zone, uniquely name your connection and click “Create New…”. This will open a new window that will ask for authentication into Azure to create the Service Principal.
Then a quick listing of the requested access will be displayed.
After you click Accept, it will create the Service Principal and present you with a wonderful green check mark, assuming all went well.
If you want to verify, log into your Azure Portal and select Active Directory. After it loads, click applications, you will see XenDesktop listed below.
After a simple click on next, you are presented with Region. Select the best region that meets your needs and on-premise connectivity. I stuck to the West for my resources.
Name your resource and select the proper subnet available in your selected virtual network based up on your region, then click next.
That is it! You are finished with the creating of the host connection. If you are accessing multiple regions, you will need to create multiple host entries.
Create your golden image
I won’t be walking you through this process as in-depth. Remember, during the VDA install, you will be prompted for the DDC you want to register with. Make sure to place all of your Cloud Connectors FQDN when you reach this step. It also helps if they are on to limit error messages and solidify installation.
Once you have the machine set up to your liking, shut it down (I shut mine down via the traditional Windows method). Then, proceed to the console or Azure Portal and stop the image machine. This places the machine in a “stop deallocated” state. It is limiting the charges and will be used for replication during the image creation process. The size of the instance that you select is dependent on the workload you have in mind. As always, choose wisely.
The size of the instance that you select is dependent on the workload you have in mind. As always, choose wisely.
Moving on up to Machine Catalogs:
When you create the machine catalog for this newly created host, make sure to make the proper selection from the drop down.
After you click on next, you will see some new options. You are presented with a complete list of all your Resource Zones to find your gold image. The hierarchy flows as follows:
Resource Zone -> Storage Account -> Container->vhds -> then the VHD you want to use
Please make sure you note the proper Resource Zone and Storage account you want to use to select your gold image for deployment.
Select the appropriate storage target for this machine catalog. Premium storage can offer you some improved performance.
Select the appropriate machine size and quantity for this group.
Next up is the network card selection.
Now, we get to name our resources and select the appropriate OU within AD.
Input the domain credentials, preferably a service account that can interact with your Active Directory for machine creations, etc.
Then you are done, time to move onto Delivery Group creation.
Upon completion of the build process, you’ll see your virtual machines listed and in a stopped state:
Delivery Group creation
We’re almost there. These steps are fairly straightforward and not that much different from an on-premise deployment.
Here is the one change from an on-premise deployed group. We are going to have Citrix Cloud manage access to the Delivery Group.
Add any applications that you want/need. I did not show this step in my screen shots.
After you have provided a company appropriate Group and Display name, time to jump back to the web console and setup access and add the service to your workspace. After you click on “add”, don’t forget to select “Update Workspace”. That way, the new service will appear when users who are subscribed to this workspace, log in.
Time to start a VM and test your deployment. The XenApp and XenDesktop Services Cloud StoreFront site provided to your company will follow the URL of “https://<your company.xendesktop.net/”. Login with the appropriate user credentials for your domain and launch.
Happy Hybrid cloud-ing!
