Deploy and configure Citrix Virtual Apps and Desktops on Azure
Deployment sequence
This domain tests the practical build: create the Azure service principal, grant rights, add the host connection in Citrix Cloud, prepare a master image, create a machine catalog with MCS, and publish a delivery group. You also need to connect users through Workspace and validate that VDAs register with the Cloud Connectors.
Core rules and concepts
- In Entra ID, register an application and create a client secret. Grant that application the required Azure role, such as Contributor, at the narrowest scope that supports catalog creation and power management.
- In Citrix Cloud, add a hosting connection for Microsoft Azure using the subscription ID, tenant ID, application ID, and secret. Select the correct region and resource group.
- Prepare a master image VM: install the VDA, join the domain, install apps, then generalize with Sysprep if the provisioning method requires it. Shut down cleanly before MCS captures the image.
- Create a machine catalog with MCS, choose the master image, machine size, disk type, number of machines, and AD account naming. Then create a delivery group and assign users.
- Validate VDA registration, Citrix Cloud connectivity, and user launch through Workspace.
Worked example
An administrator must deploy 120 task-worker desktops. They create an Entra ID app registration, add a secret, and assign Contributor on the workload resource group only. In Citrix Cloud they add an Azure host connection using that app ID and secret, select East US, and choose the workload resource group. They prepare a Windows 11 master image with the VDA, generalize it, and create an MCS catalog of 120 machines using a D4s_v5 size and standard SSD. They create a delivery group, assign the task-worker group, and test launch. The scoped role prevents the service principal from changing unrelated production resources.
Traps that cost marks
A common failure is assigning Owner or subscription-wide Contributor unnecessarily. Secrets expire; record the expiry and rotate before catalog operations fail. Forgetting to generalize the image when required causes duplicate SIDs or provisioning errors. Creating the catalog before the host connection is validated leads to opaque failures. Publishing the delivery group without a VDA registration check produces user-facing launch errors.
Key points
- Use an Entra ID app registration and client secret for the Azure host connection.
- Grant the service principal the minimum Azure role at the required scope.
- Prepare and generalize the master image before MCS provisioning.
- Create catalog, delivery group, and user assignment as separate validation steps.
- Monitor service principal secret expiry and rotate it proactively.