This post has already been read 24786 times!
It has been a while since my last blog and I thought it was time to dust the cobwebs off and get straight back in to Citrix Cloud, as there has been some evolution in the services it provides. My professional career path has deviated from the Citrix stack (for now) but I must admit it feels good to be delving in to this again. Not knowing the state of my lab, I have decided to build a new lab with the Citrix Cloud in Azure. My reasons are simple – It is quick! The purpose of this article is to provide familiarity in setting up resources accessed via the Citrix Cloud. This will be a living article and expand over time and as I learn more, so shall you.
Sign Up Process
The Citrix Cloud sign-up process is detailed here: https://docs.citrix.com/en-us/citrix-cloud/overview/signing-up-for-citrix-cloud/signing-up-for-citrix-cloud.html
If you want to know more on sizing VDA resources here are some useful links: https://www.citrix.com/content/dam/citrix/en_us/documents/white-paper/citrix-virtual-app-and-desktop-services-microsoft-azure.pdf https://www.loginvsi.com/blog-alias/login-vsi/901-citrix-virtual-app-user-density-on-aws https://www.citrix.com/blogs/2018/07/23/right-sizing-citrix-xenapp-on-google-cloud-platform/ Useful Graphs on Cost and Sizing in Azure:
First, I created all that lovely stuff in Azure that is required. - VNET - Subnets (Per machine type) - Domain Controller (You need Kerberos authentication for your VDA’s) - Resource Groups X 2 (Infra and MCS) - Master VDA (2016 VDA) - Cloud Connector - DNS - NSG
Cloud Connector Deployment
I will not go so much in to the creation of the above but will start with the Cloud Connector deployment. Log on to your domain joined Cloud Connector machine in to the Citrix Cloud control Plane. I am using a 2016 server O/S.Browse to your Citrix Cloud URL and log in to the portal.
Navigate to Resource Locations in the Hamburger Menu (Top Left):
Click to add a 'Connector' and download. Click on 'Run'.
Sign in to the Cloud Connector Prompt.
At this point the install will proceed installing relative components and services.
Some connectivity tests will be run.
Once you have installed your Cloud Connector you should see it in the Cloud Management Portal as Resource Location.
The orange warning above indicates that you have 1 Cloud Connector. My recommendation is N+1 at all times and that includes when Cloud connectors are updated one at a time. Cloud connector updates are managed by Citrix. Next, we go to the familiar Citrix Studio via the Hamburger Menu:
Azure Hosting Connection
Click on the 'Manage' tab and then 'Full Configuration'.
You will now see a familiar management console. Your Resource Location is automatically added as a Zone. More about understanding zones with CVADS can be found here: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops-service/manage-deployment/zones.html First thing is first, you will create your hosting connection.
We are creating our Resource connection in Azure. Choose this option.
Select the Azure geographic location and your zone (Resource Location). We will be using MCS as deployment method.
Next, obtain your Azure Subscription ID and choose an identifiable connection name.
In case you are wondering, the subscription ID can be obtained by looking at any object in Azure. As an example here is my Cloud Connector machine in Azure highlighting the 'Subscription ID'.
You will be asked for your Sign in credentials for your Azure subscription.
The connection to Azure will be authorised.
Click ‘Next’ to proceed.
The 'Region' will be the region that you want the VDA’s to be deployed in to.
Choose the subnets that you wish the virtual machines to use and the appropriate name.
Continue with install.
Confirm the settings and click finish.
Now, you will have a connection from your Citrix Cloud Service to your Azure subscription.
I like to carry out some checks at this stage. We can see our domain listed in Identity and Access Management.
Expand on the above to see the warning details.
Create your VDA that you will use as a master image. This involves installing the VDA on a virtual machine designated for this role in Azure. Boot up your iso and go through the familiar VDA install procedure.
Choose to create an MCS Master Image.
This next step is important. Choose the Cloud Connectors, not a Delivery Controller. It is the Cloud Connectors that will relay (proxy) traffic to the Delivery Controllers in the Cloud. Traffic is outbound on 443 from the Cloud Connectors.
I have only one Connector in this scenario. That is not enough for production!
Note: If you want to choose MCSIO feature you will need the 'MCSIO driver installed on your VDA. If not, the creation of the Machine Catalog will fail. My preference with Azure is based on cost, so I have chosen not to use MCSIO. When you choose MCSIO remember that an extra disk will be created that there is an expense for. You will need to factor this in to any cost exercise.
Accept the Firewall ports to open.
Finish the Install.
Reboot machine. I used the famously well known community tool Citrix Optimizer on my VDA as part of my VDA preparation. Link: https://support.citrix.com/article/CTX224676
Install any applications that are required for users and shut the MASTER VDA down (Deallocated). Once this is actioned, return back to the STUDIO console in the Citrix Cloud Plane and create a Machine Catalog.
Machine Catalog Creation
Create a Server VDA.
Choose the appropriate hosting connection.
Now, choose the VDA disk. Remember that the VDA used for the MASTER image needs to be deallocated. Tip: I like to take my own snapshot of the Master vhd in Azure. This way I can choose an appropriate name for the vhd. Choose the minimal functional level required.
Here is a friendly warning reminding you to deallocate the Master VDA machine.
For production you will most likely choose Premium and if you have Hybrid user rights choose this option. This will provide you with favourable reduced compute base rate costs. Use the following tool to see what your cost saving estimations could be: https://azure.microsoft.com/en-gb/pricing/hybrid-benefit/ Managed and unmanaged disks are supported with Citrix Cloud and MCS in Azure. There are advantages:
With Azure managed disks, you pay for the entire size of the disk versus unmanaged, you pay for only the blocks that are in use.
Azure Managed Disks only support VMs
Azure Storage Explorer does not show Azure Managed Disks
Deploy Cloud Connectors on Azure Managed Disks.
Managed disks are recommended because Microsoft will automatically replicate the disks to multiple storage arrays.
Citrix recommends deploying the Master VM on Azure Managed Disks.
Remember, if you use the MCSIO feature an extra disk will be created. As an example if you choose the default Disk Cache size a 127gb disk will be provisioned for MCSIO. This is not free folks. I know a good Irish man who has written an article explaining this in more depth: https://wilkyit.com/2017/11/14/machine-creation-services-azure-understanding-the-configuration-disks-and-costs-involved/
Should you choose the option, remember you need the MCSIO driver installed on your VDA.
Next screen will show your Resource Group that you will deploy the VDA’s in to. A few things to note. The Resource Group must be empty. If you want to create more than 240 machines you will need to have more ‘empty’ Catalogs pre-created if you do not have full subscription rights. You cannot add more Resource Groups later to a Machine Catalog! If you have full subscription rights to Azure, the Resource Groups will be created. Tip: Personally I like to create mine beforehand so I can provide appropriate names.
Choose the appropriate subnets that your network card for your VDA’s will use.
Choose the OU the machines will be deployed and useful Naming Scheme. Tip: I like the OU’s to be named after the Machine Catalog name and place the machines from each Catalog in corresponding OU.
Enter the Domain AD credentials. MCS must have permission to create the machines on your domain.
Review and complete.
MCS Creation Process in Azure
At this stage some funky stuff happens within Azure. The next section will describe the MCS disk creation process. Navigating back to my Resource Group I chose to deploy my virtual machines in to, I have captured some of this MCS disk creation process. (I have not caught all steps but most to provide a picture of what is happening.) For the initial step, we created a master VM with an associated disk. If the VM is created using unmanaged disks, the VHD will be placed in a Storage Account. If the VM is created with a managed disk, the disk will not be placed in a Storage Account. We then start the MCS wizard which checks via Azure API that we have the necessary connectivity and capacity. If you have full scope permissions the Resource Groups will be created as previously mentioned, if not you will have to create the Resource groups beforehand. Remember a resource group can only contain 240 VMs. A Security Group is created to isolate the preparation VM from rest of the network. This blocks any inbound or outbound traffic to the Preparation VM during its lifetime MCS then asks plugin to make sure service principal has access to the Azure resources. We now begin to see items start to populate in the empty Resource Group.
On next refresh I see a Preparatory VM is created. A preparation virtual machine (VM) is created based on the original VM. As part of the process of creating a machine catalog using MCS, the contents of the shared base disk are updated and manipulated in a process referred to as Image Preparation.
A storage account is created. This is for the preperatory Identity disk. This is a temporary step. Inside the Storage account I see the following items: (For some reason my screen shots turned black)
Within the Citrix locks are 2 .lock files.
An identity disk is created for the preparation VM. The process involves a small “instruction” disk, which contains the steps of the image preparation to run and is attached to that VM. The preparation VM is created, and because it is deployed in Azure it will start automatically. The preparation VM is forced to stop, so changes can be made. After the preparation VM stops, the identity disk is added to the VM. The preparation VM starts with the identity disk attached and runs through the preparation sequence, this involves writing the identity to the identity disk and anonymizing the master image to be used with MCS. - Preparation VM started. - Preparation VM stops after preparation. - Preparation VM disk copied to new container and used as base.
The Preparatory OS disk that appears matches the size (127gb) of our O/S.
The other disk is a 1gb preparatory Identity disk.
We now see the snapshot of the Master disk appear alongside the MCS created preparation virtual machines Identity and OS (Delta) disk.
During the Preparation Identity Disk phase the following vhd is present in the storage account.
Then a prep disk snapshot disappears. - Replicate base image to all Storage Accounts. - Delete Preparation VM and Identity disk.
All created resources are checked before VM creation process is started.
The snapshot disk reappears with the standard base name of our master disk.
The detail of the base disk is 127 gb.
Identity, OS disk and NIC disappear but the Base Disk snapshot remains.
The final creation of the Identity and OS disk of the VM plus the Nic assignment follow.
During the start of a VM, the operating system disk is created. The VM is subsequently created during the start operation and the VM is bound to the OS disk. The ID disks created is associated with the VM before starting the VM. Within the Storage Account we see the virtual machine’s identity disk. This is temporary creation step, as I do not see this later.
The objects below are shown when the process is complete.
One thing has surprised me and that is the creation of the storage account, even when creating managed disks. This appears to be for the identity disk creation process (Instruction Disk) in both preparatory and vm creation phases. The storage account is also present after the whole vm creation process, all but empty. A Machine Catalog that has deployed machines of ‘type’ in to the Azure subscription via the Azure API will now be present in the Citrix Studio console for the CVADS. The warning I see in the next screen shot is just notifying me, that I do not have the appropriate RDS licensing. Citrix allows this warning to be removed, if you wish. It is always great to see your RDS license issues highlighted, rather than wonder why your applications are not launching!
Delivery Group Creation
Heading back to the familiar Studio Console, the next step is to create a Delivery Group and assign this to the Machine Catalog. This step is necessary to provide the users the ability to access desktops and apps provided by the VDA’s in the Catalog. Again you should be familiar with the process of Delivery Group creation but let’s highlight the steps anyway.
Select the Catalog.
Assign the appropriate user access. There are options to use the familiar method of user assignment at this stage or, you could leave user management to the Citrix Cloud. This option makes use of the Library, which we will come to later.
Next, it is all about the apps and desktops you wish to publish to your user base. Detect applications via the start menu or have the option to browse to specific locations.
Tip: At this point a VDA machine is started in order to read the start menu programs. This takes some time. You could manually start your VDA in advance. The machine will turn on and go in a creating state in your Azure subscription when this happens.
Eventually, the applications will appear.
Choose your applications and then assign a desktop.
Complete the Delivery Group Assignment process specifying group name and display name. Click Finish.
We now have published App and Desktop resources for our user base.
It is a good idea to publish a Secure Browser to your end-user base for the primary reason to redirect risky internet browsing activity to an isolated, cloud-hosted browser. This is a client-less configuration.
The spiel from Citrix is here:
Citrix Secure Browser completely redirects internet browsing activities to a cloud-hosted web browser, adding layers of security. Now all your user’s risky internet browsing actions are separated from the corporate network. Citrix Secure Browser is designed to enable users to traverse the internet; however, only screen updates, mouse click and keystroke commands associated with navigating the internet cross the network to reach the user’s endpoint device on the corporate, greatly reducing the risk of data exposure or exfiltration. No website data or information resides on the user device or in the local browser cache, and nothing is left behind when the network connection is terminated, aiding security and compliance. The configuration is straight forward. Click on 'Manage'.
Then, go through initial configuration steps that will take you through a publish, test and distribute procedure.
Two options: - External Unauthenticated - External Authenticated An Unauthenticated Secure Browser can be used by anyone if they have the URL to launch it. Unauthorised Secure Browser instances are not managed in the Library. We want our resources to be controlled by Library so will choose the 2nd option.
Next, you can choose the name, browser opening page, region and icon.
Then, we will assign our users via the Library (More on this later). Click on the Library link.
Click on the 3 dots…
Choose your subscribers.
Once chosen, click the 'X' ICON at top right.
We can see the resource has subscribers (Users).
The Secure Browser also allows the ability to place some restrictions to the service which are self-explanatory.
Secure Browser also provides the ability to control access to URL content.
A test URL link is provided so you can see the experience first-hand.
Upon launch the browser opens a secure connection to our chosen web page URL.
I tested watching a new movie trailer. To be fair, the video playback was impressive.
I am also able to track the usage of the Secure Browser Service.
This is an effective secure way to provision a browser to your end users. Once accessing the published resources, the browser will appear as an application. The option to publish this browser to users via the Library or provide them a URL they can access can be granted by the Citrix Cloud Administrator.
As we have just touched upon this concept let’s provide some context. All resources that you provide users with, are shown in this Library portal. You can assign user/groups to published resources. The below screenshot shows a published Secure Browser (More on this later), Desktop and applications that my user base can access. The Cloud Connector is communicating with the Active Directory and can browse and assign specific users/groups. The option to ‘Leave user management to Citrix Cloud’ in the Delivery Group Wizard lets you assign the relative access within the Library.
Peeking within the Zones node I see my Cloud Connector, Hosting Connection, Machine Catalog and User Group. In a multi-site scenario (Again, more on this in a later blog) my user (in this example) will connect to VDA resources in the Azure location.
Workspace Portal and 2FA
There must be a way to connect to the resources we have published at this point. Welcome to the Workspace. The URL users connect to that is customisable and the same can be said of the portal look and feel. This is somewhat limited currently. The great thing about this is you have one less secure certificate to worry about.
With Citrix Cloud Workspace you can also choose to leverage the Gateway Service with multiple points of presence over the globe backed with a Cedexis backbone that will find the best routable access for your users. Traffic Flow of VDA and Gateway Service is explained in the following article: https://virtualfeller.com/2018/07/17/cloud-connector-vda-to-gateway-service/ You can read more about Cedexis and Intelligent Traffic Management here:
The very complicated configuration is shown below 😉
Workspace will allow you to configure Authentication methods. We now have Active Directory + Token giving the ability of Two Factor using applications such as Google Authenticator. This feature is termed as Active Directory + Time Based One Time Password. First you must enable this Authentication method in Identity and Access Management (in Citrix Cloud management portal) then, you assign it to the Workspace as an authentication method. I have tested this authentication and it is simple and effective. This is a great move and pretty slick! One more reason to go to Citrix Cloud!
The screen below shows the Authentication access I have for my user after enabling 2FA in the Citrix Cloud. First step, if not done so before would be to click on the ‘Don’t have a token?’ link.
Input Domain/username details and click next.
If you come across the error in the next screen shot, you must input an email address within the AD user account.
I populated my user1 email address. Provide the relevant information for your user.
This allows you to progress and an email will be sent out to complete device registration. The example shows an email sent to my Gmail account.
Within the email body you will see something like the following:
Take the code provided so it can be added to the ‘Verification Code’ option along with your user password. Click ‘Next’.
Next, you are presented with a barcode that your mobile phone can scan using an application like Google Authenticator. https://support.google.com/accounts/answer/1066447?co=GENIE.Platform%3DAndroid&hl=en
Once this is done, I will be authenticated securely and have access to my applications, desktops, secure browsers.
I hope this article is useful and highlights the way you can effectively use Citrix Cloud Virtual Apps and Desktops Service using an Azure Resource Location along with Secure Two Factor Authentication to gain access to your Apps, Desktops and Secure Browser. With the introduction of additional security features and Cedexis (ITM), an improved Gateway Service and traffic Flow. I can easily see reasons why Enterprises should start the adoption of Citrix Cloud. It is a complete no brainer in a Multi-Site scenario and I will have more to say on this in my next blog.
For now, it is time to log off.
Errors Encountered on the Journey
Error 1 Encountered when I was unable to remove an old Delivery Group from Citrix Cloud Studio. Error 2 Encountered when I installed the Cloud Connector Software without Administrative rights. Error 3 Encountered when using _ character in naming scheme for VDA. Error 4 Encountered when carrying out MCS catalog provisioning. My Azure based subscription did not have enough cores. https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits Error 5 Encountered when trying to provision a catalog using MCSIO without appropriate MCSIO driver being present on VDA. https://www.jgspiers.com/citrix-fixes-machine-creation-services/ Error 6 Encountered due to mismatch with Subnet between Domain Controller and VDA. Error 7 Encountered due to Domain Firewall being on and partly due to the subnet mismatch in previous.