In the End-User Computing community, there’s an influx of interest in introducing, or changing to, public cloud-based solutions for VDI (Virtual Desktop Infrastructure). This interest is leading some to Citrix Cloud. Part 1 of this blog series touched on the Citrix Cloud Virtual Apps and Desktops service architecture, its available regions and its global footprint. In part 2, we continue to help you decide if the Citrix Cloud Virtual Apps and Desktops service is right for you.
For a service such as VDI that is crucial to your organization, the decision to move to the cloud can be a weighty one. But it doesn’t have to be. The right knowledge will make it easier to decide. Here’s a list of common questions and answers that should help.
The supported cloud providers for resource locations are Microsoft Azure, Amazon Web Services (AWS), Google Cloud Platform, Oracle Cloud, and IBM Cloud.
As discussed in part 1, Citrix Cloud runs on Azure. Because of this, Azure tends to be the most recommended cloud provider—since it integrates with everything Citrix Cloud brings to the table: power management, Machine Creation Services (MCS) support, and (in some scenarios) virtual machines that perform better, when compared to AWS. You can also leverage other services in Citrix Cloud, such as App Layering to be supported directly with Azure.
But AWS also plays well. Many traditional hosted shared desktops and apps run great on AWS since they have lots of feature parity.
Google has better prices, is more flexible, and is rumored to be faster than Azure & AWS in performance testing. Google’s only limitation is it lacks all the Citrix on-prem features, but Citrix is working to close the gap on that this year, and not all customers require the features that are absent.
The supported hypervisors for resource locations are Microsoft Hyper-V, VMWare ESXi, Citrix Hypervisor (formerly XenServer), and Nutanix AHV.
These all have their supporters, however for most environments the choice will be dictated by what is already running in the organization.
There are currently 3 release strains: Current Release (CR), Long Term Service Release (LTSR) and Cloud Release. You can mix and use the latest CR or LTSR with Citrix Cloud.
If you use Windows Server 2016 or 2019, you may want to use the CR version of the VDA. If you use Windows Server 2008 R2, best to use the LTSR version of the VDA.
Take a look at the “top eight killer features” in CR.
Citrix Virtual Apps and Desktops service is licensed on a per-user basis. On-prem user licensing options (user/device or concurrent) are not available in the cloud service.
Licenses can be released by the admin after 30 days of user inactivity, versus 90 days with on-prem Citrix license server. Concurrent licenses are also offered in a premium-plus package, for some hybrid transactions.
The main deployment types are:
Six identity and access management providers may be used to administer and subscribe to Citrix Cloud. The default is Citrix Identity provider, but you can change this to use on-prem AD, AD plus token, Azure AD, Citrix Gateway, or Okta.
Citrix Cloud hosts the management stack on Azure, while workloads and Active Directory stay within your resource locations. So, from a security standpoint, they don’t touch core IP—not even with Machine Creation Services, which is simply using host connection APIs for clone and power management of the supported cloud provider or hypervisor. Citrix can’t get into them and does not store sensitive customer information. With Active Directory, Citrix conducts a live read only, and gets out. Active Directory is never synced to the cloud; it stays within the resource location. Then, as with all configurations, there’s metadata (which user logged-in, etc.) that is hosted in the cloud with a logical partition (which Citrix makes sure is isolated so there’s no data leakage). For this data-in-flight, industry standard Transport Layer Security (TLS) 1.2 is used with strong cipher suites over port 443.
You may also use the Service Health Dashboard website mentioned above for transparency into security issues that can impact customers.
As of March 15, 2019, communication over TLS 1.0 and 1.1 has been blocked to improve security. Only TLS 1.2 is permitted. This means you’re required to use the latest versions of Citrix Receiver or the Citrix Workspace app:
If you need to be FIPS (Federal Information Processing) compliant, support for that standard is available.
The Virtual Apps and Desktops service handles 4 types of credentials: User credentials, Admin credentials, Hypervisor passwords, and AD credentials.
User credentials come into play when using customer-managed StoreFront servers. In this scenario, credentials are encrypted by the Cloud Connector using AES-256 encryption and a random one-time key generated for each launch. The key is then passed to the VDA by the Citrix Workspace app (formerly Citrix Receiver) to decrypt the password during single sign-on session launch. The following diagram helps visualize the flow.
Admin credentials come into play when you authenticate into Citrix Cloud. In this scenario, a one-time JSON Web Token (JWT) is generated to provide access.
Hypervisor credentials are needed when on-prem hypervisors are configured for a host connection. The credentials are stored encrypted in an SQL database in the cloud.
AD credentials come into play when Machine Creation Services uses Cloud Connectors for provisioning machine accounts in the customer’s AD.
For environments that require a higher level of resiliency, the local host cache feature is available to enable users to continue working when, or if, a Cloud Connector loses communications with Citrix Cloud for 20 seconds, but the caveat is (as a requirement) you must have an on-prem StoreFront per resource location.
Please stay tuned for part 3 of this series where we’ll continue to help you decide if the Citrix Cloud Virtual Apps and Desktops service is right for you.
Lastly, to learn more about Citrix Cloud Virtual Apps and Desktops service or Desktop as a Service, please reach out to us. We’d love to help you!
Architect, End User Computing at Anexinet
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
|cookielawinfo-checbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.