We all know, Citrix initially was into provisioning apps and desktops to users. They came up with Citrix Cloud services where Citrix manages the admin part and you manage the VDI part (mostly).
Now they came up with another service where you can host the VDIs on Microsoft Azure and Citrix will help to manage the connection between your organization users and Azure. Now let’s see Citrix Managed Desktops is.
Citrix Managed Desktops (CMD) :
Citrix Managed Desktops is a turnkey Microsoft Azure hosted solution to deliver virtual desktops and apps. The admin can deliver Windows 10 multi-session desktops, Windows 10 Enterprise and Windows 7 ESU single session desktops. Also, Windows Server 2008 R2, 2012 R2, 2016, and 2019 OS sessions or apps running on any of the above OS using a GUI interface in just a few clicks.
In a nutshell, CMD is providing Microsoft Azure VDIs to end users through Citrix.
As this is Desktop-as-a-Service, Citrix will bill you monthly as a whole – for their CMD, and the backend Azure service if you use CMD Azure service for the VDIs. If not, you will get a bill for CMD and another bill for Azure that you manage on your own.
With this option, organizations in the U.S., the E.U., and Asia/Pacific can deploy the VMs in four Azure locations globally: U.S. East, U.S. West, West Europe, and Australia East.
What if I already have Azure Subscription?
If you already have Azure subscription, you can use the same subscription to provision VDIs to end users through CMD. In the CMD console, you can specify your Azure subscription details while creating catalog. With CMD there are two deployment types:
- Non-Domain Joined
- Domain Joined
Non-Domain joined deployment types are the ones where VDIs are not joined to any domain. This is best for POCs, dev/test environments, or small organizations where they don’t have on-premises AD or an Azure AD.
In the Non-Domain joined model, as users and machines are not on the same domain, we have to somehow bind the user’s ID to the machine. A wrapper token encapsulates user ID token and uses (Citrix Managed or the organizations) Azure AD or the organization’s AD. This wrapper token is used to create a mapped account for the user identity on the machine.
User’s credentials/account on that VDI is created by data that is stored in the Azure AD or organization’s AD and the associated password is stored securely. This process is done by a privileged service. The service creates an account for the user on the machine if it’s the first time ever the user is logging on to the machine. When a user authenticates to the Workspace with the preferred identity, the local mapped account’s user name password information is retrieved. The retrieved credentials are in turn used to log in to the machine.
We have 3 options for user accounts in Non-Domain joined deployment type and the name says what it does.
1. User accounts in Citrix Managed Azure Active Directory
2. User accounts in Customer’s Azure Active Directory
3. User accounts in the organization’s on-premises Active Directory
Here user’s VDIs are added to the organization’s AD. We have 3 types of deployment here:
1. Domain joined using Azure Active Directory Domain Services and user accounts in organization’s Azure Active Directory
Here the users’ accounts are in the organization’s Azure Active Directory and the machines are joined to the Azure Active Directory Domain Services (AADDS) within the customer’s Azure subscription. For the machines to be able to connect to the AADDS you need to setup Azure VNet Peering from the network in Citrix Managed Desktops’ Azure subscription to your own Azure network in their subscription.
2. Domain Joined to the organization’s on-premises Active Directory via Azure Active Directory Domain Services and users’ accounts in the organization’s on-premises Active Directory
Here the users’ accounts are in the organization’s on-premises Active Directory. The Active Directory is synced with the Azure AD in the customer’s Azure subscription using Azure AD Connect. This setup allows the user’s identity to be authenticated from the synced Azure AD. For the machines to be able to connect to the on-premises AD, the customer needs to set up Azure VNet Peering from the network in Citrix Managed Desktops’ Azure subscription to their own Azure network in their subscription. Another connection to the data center for access to profile and app data and file servers is needed. The second connection requires SDWAN or a site-to-site VPN or an Express Route.
3. Domain Joined to and users’ accounts in the organization’s on-premises Active Directory
User’s machines (VDI) and User’s accounts are in the organization’s on-premises AD. CMD Azure subscription and customer’s on-premises locations are connected to each other using SD-WAN. These appliances are managed by the customer using the SD-WAN Orchestrator in Citrix Cloud. This deployment is the simplest (as there is no need for syncing the on-prem Active Directory with the customer’s Azure AD) and utilizes the optimizations built into SD-WAN to help ensure that the user gets the best experience possible.
In CMD, we can manage our VDIs using MCS. With CMD MCS we can,
1. Use Windows 10 or Windows 7 ESU (Extended Security Updates)
2. Use Windows 10 Multi-Session available in Azure. Multiple users can connect to these machines. Note that this type of machine does not require RDS CALs for allowing multiuser access.
3. Windows Server 2008 R2 / 2012 R2 / 2016 / 2019 are server operating systems that allow multiple users to connect to a single machine.
While creating a catalog you have options to “Quick Create” or “Custom Create“.
- Quick Create lets you choose the size of VDI you need, region, name and number of VDIs to create. It only creates static machines, provisioned through managed AD (Citrix Azure), no connection to your organization network, Citrix managed image, and Power Management.
- With Custom Create, you can select multi-session OS or static or random type, choose your own Azure subscription, region, storage type, workload, and master image. Workload offers light, medium, heavy and custom type VDIs.
For more info check out this Video: