Tech Brief: Citrix Provisioning

Overview

Citrix Provisioning (PVS) is different from traditional imaging solutions, fundamentally changing the relationship between hardware and the software that runs on it. A shared disk image is streamed over the network rather than copied to virtual machines. This single shared-disk image (vDisk) is created by imaging a machine called the master target device. Administrators need to determine the type of machines (OS, Software, and so forth) to deploy for the user base in their organization. Then, based on that decision, the master target device is created. The vDisk is streamed to multiple machines (target devices), which users then access. By streaming this read-only single shared disk image rather than copying images to individual machines, Citrix PVS enables organizations to reduce the number of disk images they manage, even as the number of devices grows. Citrix PVS gets you the operational benefits of centralized management while still scaling your machines quickly and efficiently.

This document provides an overview of product functionality and conceptual architecture for Citrix Provisioning Services.

Citrix Provisioning Services Architecture

A Citrix Provisioning Services farm represents the top level of the Provisioning Services infrastructure. A farm includes all the components that make up the Provisioning Services deployment. These components include:

• Citrix Provisioning Server
• SQL Database
• Citrix License Server
• Local and network shared storage
• Collections of target devices.

A Citrix Provisioning site provides a way of representing and managing logical groupings of Provisioning Servers, Device Collections, and local shared storage. One or more sites can exist within a farm. The first site is created with the Configuration Wizard and runs on the farm's first Provisioning Server.

The Citrix Provisioning Server is a server that has the Citrix Provisioning Soap and Citrix Stream Services installed. The Stream Service is used to stream software from virtual disk images or vDisks to target devices. The Citrix Provisioning Services console uses the PVS Soap Service for connections. Provisioning Servers stream the contents of a vDisk file (containing a machine image) to target devices. vDisk files can reside directly on the Provisioning Server's local hard disk, or Provisioning Servers can access the vDisks from a shared-storage device on the network.

The Citrix Provisioning Services database requires a SQL database to store all system configuration settings within a farm. Citrix Provisioning Server advanced configuration options ensure high availability and load-balancing of target device connections between PVS Servers.

A Citrix License Server is required for the entire Citrix Provisioning Services deployment. An Existing Citrix License Server can be used to provide licenses.

Citrix Provisioning Device Collection

Device collections provide the ability to create and manage logical groups of target devices. Creating device collections simplifies device management by performing actions at the collection level rather than at the target-device level. A target device can only be a member of one device collection.

A device, such as a desktop computer or a virtual machine that boots and gets its OS image from a PVS virtual disk on the network are considered a target device. A device used to create the base personal vDisk image is considered a master target device. vDisks act like a hard disk for a target device and exists as disk image files on storage accessible by the PVS Servers. A virtual disk consists of a VHDX base image file, any associated properties files (.pvp), and optionally a chain of versioned VHDX differencing disks (.Avhdx).

A store is a logical name for the physical location of the folder containing vDisks. This folder exists on a PVS server or shared storage. Virtual disk files in the PVS Console are assigned to a store when created in the PVS Console. Within a PVS site, one or more Provisioning Servers can access that store to serve vDisks to target devices.

When the virtual disk is in private/maintenance mode, all data write back to the virtual disk file. Data cannot be written to the base-virtual disk when the virtual disk is in standard mode or shared mode. Instead, data writes to a cache file in one of the following locations:

• Device RAM

• Device RAM with overflow on the hard disk

• PVS Server

This write cache file deletes on the next boot cycle. When a target is rebooted or starts up, it has a clean cache and contains nothing from the previous sessions, thus guaranteeing the consistency of the image.

PVS target software redirects the system page file to the same disk as the write cache file, so pagefile.sys allocates space on the cache drive unless manually setup to be redirected on a separate drive volume.

Cache in device RAM

Write Cache can exist as part of the non-paged pool in the target device's RAM. This functionality provides the fastest disk access method since memory access is always faster than disk access.

This mode is useful when the server has enough physical memory, and it is faster than other cache modes. It is vital to pre-calculate workload requirements and set the appropriate RAM size. Otherwise, the target device may bluescreen because of insufficient space before the write cache is exhausted.

Cache on device RAM with overflow on hard disk

This method has moderate consumption of RAM and hard disk. Citrix recommends using this cache type because it combines the best of RAM with the stability of the hard disk cache. The Cache uses non-paged pool memory for the best performance. The oldest RAM cache data write to the local disk when RAM utilization has reached its threshold.

Cache on PVS server

The write cache can exist as a temporary file on a Provisioning Server disk. This method generally increases network traffic as disk writes redirect to a remote location from the target device.

This cache type is not recommended for a production environment as it is slower than the other options.

Active Directory Integration and Target Device Management

Integrating Citrix Provisioning and Active Directory allows administrators to select the Active Directory Organizational Unit (OU) in which Citrix Provisioning should create a target device computer account. It also allows it to take advantage of Active Directory management features, such as delegation of control and Group policy. Finally, configure the Provisioning Server to automatically manage the computer account passwords of target devices.

Citrix Provisioning Services Image Lifecycle

Citrix Provisioning supports an entire image lifecycle that takes a virtual disk from initial creation, deployment, subsequent updates, and retirement. The lifecycle of a virtual disk consists of four stages:

Creating > Deploying > Updating > Retiring

Creating a virtual disk Creating a virtual disk requires preparing the master virtual machine for imaging, creating, and configuring a virtual disk store where the vDisks resides and imaging the master target device (VM) to that file that results in a new base-virtual disk image. The Citrix administrator does this process using the Imaging Wizard.

Deploying a virtual disk Once created, the base-virtual disk image gets deployed by assigning it to one or more target devices. When the target device starts, it boots from an assigned virtual disk. There are two boot mode options. Private Image mode (single device access, read/write), and standard image mode (multiple device access, read-only with write cache options).

Updating a virtual disk It is necessary to update a base-virtual disk image over its lifecycle to contain the most current software and patches. The update process can be performed manually or automated using virtual disk Update Management features. A new version gets created each time a virtual disk is updated. Different devices can access different versions based on the joint classification of the target device and virtual disk version: test, maintenance, or production.

A maintenance device has exclusive read/write access to the newest maintenance version, test devices have read-only access to test versions, and production devices share read-only access to production versions.

Updating a virtual disk involves the following:

• Create a version of the virtual disk, manually or automatically

• Boot the newly created version from a Maintenance or Update device, install and save any changes to the virtual disk, then shut down the device

• Validate with a test target device, then promote to production and reboot all the production target devices

Retiring a virtual disk Retiring a virtual disk is the same as deleting it. The entire VHDX chain, including differencing and base image files, properties files, and lock files, are deleted after being unassigned.

High Availability of Citrix Provisioning

The key to establishing a highly available Citrix Provisioning environment is identifying the critical components, creating redundancy for the vital components, and ensuring automatic failover to the secondary server if the active server fails. Essential components for Citrix Provisioning include:

• SQL Database

• Provisioning Servers

• vDisks and storage

Citrix Provisioning provides several options to consider when configuring for a highly available implementation, including:

Offline Database Support - Provisioning Servers can use a local snapshot of the database if the connection to the database is lost to allow continued functionality.

SQL AlwaysOn - Citrix Provisioning supports the SQL Always On high availability and disaster recovery solution.

Database mirroring - A high availability solution for SQL Server implemented at the database level.

Provisioning Server Failover - If one of the PVS servers becomes unavailable, another server can handle the active target device connections with the virtual disk. Load balancing is enabled to automatically balance the target devices and the remaining servers.

vDisks and Storage - Provisioning Servers are configured to access a shared storage location. Citrix Provisioning supports various shared storage configurations, including Windows shared storage and SANs.

Reference: Citrix Docs: Managing for highly available implementations

Licensing a Citrix PVS Deployment

Citrix License Server The Citrix License Server is installed on a Windows server within the Citrix environment to communicate with all Citrix PVS servers to activate the licenses for PVS Servers. The License Server grace period is 30 days (720 hours). Citrix Provisioning continues to provision systems for 30 days if connectivity to the Citrix License Server is lost. Microsoft clustering functionality can create clustered License Servers to achieve scalability reliability and increase the availability of the Citrix License Server.

Citrix Cloud Provisioning License Type Citrix introduced a license type (PVS_CCLD_CCS) that provides a traditional PVS license entitlement to customers of the DaaS in Citrix Cloud. Citrix Provisioning license options for Citrix Cloud are associated with Citrix Provisioning license types, on-premises, or Citrix Cloud. Citrix Cloud licenses are consumed using a License Server with Citrix Provisioning if the Cloud option is selected during the initial setup. Conversely, an on-premises license is consumed if on-premises is selected when setting up Citrix Provisioning.

Note: This Citrix Cloud license type replaces the existing on-premises Citrix Provisioning license for Desktops and Provisioning for Data Centers. It has the same license-acquiring precedence as the on-premises licenses when bundling Citrix licenses.

The on-premises trade-up feature does not apply to Citrix Cloud licenses. Each Citrix Provisioning target device checks out a single Citrix Cloud license regardless of the operating system type.

Microsoft Volume Licensing When running the PVS imaging wizard to create the virtual disk, configure the Microsoft Key Management Service (KMS) or Multiple Activation Key (MAK) volume licensing option that enables the Citrix Provisioning Server to activate the operating system of each target device.

KMS volume licensing uses a centralized activation server that runs in the data center and serves as a local activation point (opposed to having each system activate with Microsoft over the internet).

A MAK corresponds to some purchased OS licenses. The MAK is entered during the installation of the OS on each system, which activates the OS and decrements the count of purchased licenses centrally with Microsoft. Alternatively, a 'proxy activation' process is done using the Volume Activation Management Toolkit (VAMT allowing activation of systems that do not have network access to the internet. Citrix Provisioning uses this proxy activation mechanism for Standard Image Mode vDisks that have MAK licensing mode selected when the virtual disk is created.

Target Device Boot Process

When a target device powers on, it needs to find and contact a Provisioning Server to stream down the appropriate virtual disk. This information is stored in the bootstrap file named ARDBP32.BIN. It contains everything that the target device needs to contact a Citrix PVS server to initialize the streaming process. The bootstrap file, delivered through a TFTP server, also partly applies to the alternative BDM (Boot Device Manager) approach. There are some distinct differences between TFTP and BDM.

TFTP When using TFTP, the target device needs to know how and where to find the TFTP server to download the bootstrap file before connecting to the PVS Server. TFTP can be configured in HA through a NetScaler to avoid a single point of failure. Provisioning Services has its own built-in TFTP server. One of the most popular approaches to delivering the TFTP server address to target devices is DHCP (though there are other options).

BDM (Boot Device Manager) There are two different methods to make use of the Boot Device Manager. PVS offers a quick wizard which generates a relatively small .ISO (around 300 KB) file. Next, the administrator configures the target devices to boot from this .ISO file using their virtual DVD drive. This method uses a two-stage process where the PVS server location is hardcoded into the bootstrap file generated by BDM. Like the PVS device drivers, the remaining information is downloaded from the PVS server using a TFTP protocol (UDP port 6969) here; TFTP will still be used.

When using the Virtual Apps and Desktops Setup Wizard to provision target devices, an administrator can create and assign a small BDM hard disk partition, which will be attached to the virtual machine as a separate virtual disk. When used, the above-mentioned two-stage approach is no longer needed because the partition already contains all the PVS drivers. This way, all the required information is directly available without PXE, TFTP & DHCP.

The above diagram illustrates the high-level boot steps. PXE is used to get the clients' TFTP server IP and bootstrap file name details, and TFTP is used for downloading the bootstrap program file.

Citrix Provisioning Optimization

In previous releases of Citrix Provisioning a number of optimzations were recommended to be implemented. No longer do administrators need to adjust port and thread configuration or dedicate a streaming network for Citrix Provisioning. For updated guidance on your Citrix Provisioning design, please refer to the following: Make device management simpler with Citrix Provisioning

Citrix Provisioning managed by Citrix Cloud

Citrix PVS and Citrix Cloud integration are essential when an admin manages their deployments from anywhere using the Citrix Cloud portal. The Citrix Cloud Connector plays a key role. It enables communication with provisioned VDAs in the Citrix Cloud DaaS, providing proxy functionality for commands to remote hypervisors and clouds. There are a few elements to be considered when using Citrix Provisioning with Citrix Cloud.

• Citrix Virtual Apps and Desktops Delivery Controller in Citrix Cloud

• Citrix Cloud Connector located in one or more resource locations

• Provisioning Server located on-premises (v7.18 or later)

• Remote PowerShell SDK used by Citrix Virtual Apps and Desktops Setup Wizard to push VDA records to the Delivery Controller in Citrix Cloud.

To connect an existing Citrix Provisioning deployment to Citrix Cloud:

• Add Cloud Connector servers

• Upgrade Citrix Provisioning to version 7.18 or later

• Install the Remote PowerShell SDK on the Citrix Provisioning Console with Citrix Virtual Apps and Desktops.

Citrix Cloud integration enables Citrix Provisioning to add the newly provisioned VDAs to a machine catalog in the Citrix DaaS Delivery Controller located in Citrix Cloud. This process follows one of these two methods:

• Add new devices using the Virtual Apps and Desktops Setup Wizard in the Citrix Provisioning Console

• Import the existing Citrix Provisioning target devices using the Machine Catalog creation in Studio

Citrix Studio uses the PvsPsSnapin to communicate with the PVS Server. This snap-in enables Citrix DaaS communications to the PvsMapiProxyPlugin (Citrix Cloud Connector). Communication happens over HTTPS (TCP 443). The PVS administrator credentials are sent over this secure channel. The proxy then uses the credentials to emulate the PVS administrator before contacting the PVS server.

Citrix Provisioning Services for Public Cloud

Using the same provisioning tools and policies as used with on-premises hypervisors, Citrix Provisioning workloads are available for Microsoft Azure and Google Cloud Platform. This functionality includes support for the Citrix Virtual Apps and Desktops Setup Wizard. It integrates with the Citrix DaaS using the same tools that administrators already know.

Citrix Provisioning Services on Microsoft Azure

When using Citrix Provisioning in Microsoft Azure, the Citrix Cloud contains Citrix Desktops-as-a-Service (DaaS), including the following:

• Connection Broker, the delivery controller service that responds to desktop or application launch requests, maintains the appropriate number of unused, powered-up machines in the site, maintains regular contact with powered-up devices, and monitors the machines and users' state sessions.

• Connection Broker Catalogs that reference Citrix Provisioning Target VMs running on Azure. The broker catalogs define the allocation type (static or random), how machines are provisioned (PVS, MCS, or manually), and if they are single or multi-session machines.

When using Citrix Provisioning in Microsoft Azure, the Azure subscription contains the following:

• Citrix Cloud Connectors are a Citrix component that serves as a channel for communication between Citrix Cloud and the Azure resource locations. The Citrix Cloud Connectors enable cloud management without requiring complex networking or infrastructure configuration and removes the hassle of managing delivery infrastructure.

• Citrix Provisioning Servers, installed on a server-class Azure virtual machine, and as with on-premises Provisioning Service deployments, the rules for providing high availability and the locality of the connection apply. The Citrix Provisioning Server also hosts the Citrix Provisioning console, the utility used to manage the Citrix Provisioning implementation.

• Citrix Provisioning Service database, setup as an Azure SQL database, Azure SQL Managed Instance, or a Microsoft SQL Server or Server Express setup on a server-class Azure virtual machine.

• vDisks in which the standard processes for providing storage apply. Local storage can be used on the Provisioning Server VM and manually manage replication of vDisks between servers. Azure Files can provide an SMB server accessed from any server in the region. A Premium Storage account is required to host Azure Files. Azure NetApp Files is also supported for vDisk storage.

• The Citrix Provisioning master VM is used to capture a virtual disk. You create the VM manually on Azure, installing the Citrix Provisioning Target Driver package. The mechanisms for this and the subsequent capture of a virtual disk from the master VM are essentially the same as existing on-premises installations.

• Target VMs, which boot using a small boot disk. The Citrix Provisioning Server and targets do not support either PXE or ISO boot because these boot options are unavailable in Azure. Instead, target VMs boot using a small boot disk, the BDM Boot Disk, about 20 MB and contains the Citrix Provisioning UEFI boot application. Once the BDM app is running, it uses the Citrix Provisioning protocol to stream the virtual disk contents to the VM. If you plan on manually provisioning target VMs, you can use the BDM.exe tool to create a VHD file that is the boot image.

Citrix Provisioning Service on Azure supports classic Active Directory only. Classic Active Directory can be made available on Azure in one of the following ways:

• Enable Azure Active Directory Domain Services feature for the Azure tenant (directory). If you require connectivity with your corporate Active Directory service, install and configure Azure AD Connect on a server in your data center. Azure AD Connect synchronizes your on-premises domain controllers and the Azure AD directory.

• Create Active Directory domain controller VMs in your subscription and connect to an on-premises forest via an ExpressRoute connection.

• Create a stand-alone Active Directory domain by creating AD Domain Controllers in your subscription.

Access to a Citrix License server is required, either an on-premises license server that you access via ExpressRoute or a separate VM on Azure.

Reference: Citrix Provisioning Services on Microsoft Azure Architecture

• Citrix Virtual Apps and Desktops Setup Wizard is available to provision target VMs and add them to a Citrix DaaS catalog.

• Citrix Provisioning Import and Export wizards. The Import wizard allows you to import manually provisioned VMs into the provisioning server. In contrast, the export wizard lets you create and update catalogs in Citrix DaaS from manually provisioned targets.

• Azure master VM creation allows a master VM in Azure to act as the source of the vDisk to be used by the PVS server and create and update this vDisk using either Provisioning versioning or reverse imaging.

• Image Portability Service support. See Citrix IPS for more information.

• Secure boot and trusted launch

• Generation 1 (BIOS) VMs

• Cache on device hard disk, Cache on device hard disk persisted, and Cache in device RAM

For other limitations, refer to Citrix Provisioning Services on Microsoft Azure Limitations

Citrix Provisioning on Google Cloud Platform

When using Citrix Provisioning in Google Cloud Platform, the Citrix Cloud contains Citrix DaaS, including the following:

• Connection Broker, the delivery controller service that responds to desktop/application launch requests, maintains the appropriate number of unused, powered-up machines in the site, maintains regular contact with powered-up devices, and monitors the machines and users' state sessions.

• Connection Broker Catalogs that reference Citrix Provisioning Target VMs running on Azure. The broker catalogs define the allocation type (static or random), how machines are provisioned (PVS, MCS, or manually), and if they are single or multi-session machines.

• MCS HCL plug-in that power managed the virtual machines in GCP subscription.

When using Citrix Provisioning on Google Cloud Platform, the GCP subscription contains the following:

• Citrix Cloud Connectors are a Citrix component that serves as a channel for communication between Citrix Cloud and the GCP resource locations. The Citrix Cloud Connectors enable cloud management without requiring complex networking or infrastructure configuration and removes the hassle of managing delivery infrastructure.

• Citrix Provisioning Servers, installed on a server-class GCP virtual machine, and just as with on-premises Provisioning Service deployments, the rules for providing high availability and the locality of the connection apply. The Citrix Provisioning Server also hosts the Citrix Provisioning console, the utility used to manage the Citrix Provisioning implementation.

• Citrix Provisioning Service database, setup as a Microsoft SQL Server or Server Express setup on a server-class GCP virtual machine.

• vDisks in which the standard processes for providing storage apply. Local storage can be used on the Provisioning Server VM and manually manage replication of vDisks between servers. In addition, a separate VM that acts as a file server for sharing vDisks can be used.

• The Citrix Provisioning master VM is used to capture a virtual disk. You create the VM manually on GCP, installing the Citrix Provisioning Target Driver package. The mechanisms for this and the capture of a virtual disk from the master VM are essentially the same as existing on-premises installations.

• Target VMs, which boot using a small boot disk. The Citrix Provisioning Server and targets do not support either PXE or ISO boot because these boot options are unavailable in GCP. Instead, target VMs boot using a small boot disk, the BDM Boot Disk, about 20 MB and contains the Citrix Provisioning UEFI boot application. Once the BDM app is running, it uses the Citrix Provisioning protocol to stream the virtual disk contents to the VM. If you plan on manually provisioning target VMs, you can use the BDM.exe tool to create a VHD file that is the boot image.

Citrix Provisioning Service on GCP supports classic Active Directory only. Classic Active Directory can be made available in GCP in one of the following ways:

• The GCP Managed Microsoft AD feature can be used to create an AD domain managed by GCP.

• You can create a classic AD domain within your subscription by creating a VM that is configured as a domain controller.

Access to a Citrix License server is required, either an on-premises license server that you access via VPN or a separate VM on GCP.

Reference: Citrix Provisioning Services on Google Cloud Platform

The following Citrix Provisioning features are supported in the preview release when provisioning workloads in GCP:

• UEFI boot of GCP VMs.

• Streaming 64-bit Windows Server 2016, 2019 and 2022 target VMs.

• Provisioning target VMs using the Citrix Virtual Apps and Desktops Setup wizard.

• Manual provisioning of target VMs using the GCP APIs or gcloud CLI directly.

• Using import wizard to import manually provisioned VMs into the Citrix Provisioning server.

• Using export wizard to create and update Broker catalogs in Citrix DaaS (formerly Citrix DaaS) instances.

• Creating virtual disk from a GCP master VM and updating using either Citrix Provisioning versioning or reverse imaging to the same master VM.

• Manually configuring master VMs to start from the Citrix Provisioning server to do imaging tasks. An updated BDM.exe and PowerShell script is provided as a help.

• Windows 10 and Windows 11 desktops. Sole tenant node is not supported. Therefore, only Windows server target VMs licensed by Google can be run.

• In this preview release, all provisioning target VMs are billed by Google as Server 2019 VMs. A future release will update this to use the license from the original master VM.

• PXE and ISO boot of master and target VMs.

• Legacy BIOS boot of streamed VMs. Only UEFI is supported.

• 32-bit OS support.

• Windows Server release before 2016 are not supported.