Citrix Provisioning Definitions

Website Visitors:


A farm represents the top level of a Provisioning Services infrastructure. Farms provide a “Farm Administrator” with a method of representing, defining, and managing logical groups of Provisioning Services components into sites.

All sites within a farm share that farm’s Microsoft SQL database. A farm also includes a Citrix License Server, local or network shared storage, and collections of target devices. The farm is initially configured when you run the Configuration Wizard. The wizard prompts you for the farm’s name, a store, and a device collection. When you first open the Console, those objects display in the tree.


A site provides a method of representing and managing logical groupings of Provisioning Servers, Device Collections, and local shared storage. A site administrator can perform any task that a device administrator or device operator within the same farm can perform.

Note: Under single farm you can create multiple sites.


A Provisioning Server is any server that has Stream Services installed. Provisioning Servers are used to stream software from vDisks, as needed, to target devices. In some implementations, vDisks reside directly on the Provisioning Server. In larger implementations, Provisioning Servers get the vDisk from a shared-storage device on the network. Provisioning Servers also retrieve and provide configuration information to and from the Provisioning Services database. Provisioning Server configuration options are available to ensure high availability and load-balancing of target device connections

To configure a Provisioning Server and software components for the first time, run the Configuration Wizard (the Configuration Wizard can be re-run on a Provisioning Server at a later date in order to change network configuration settings). After the Provisioning Server software components are successfully installed, and the wizard configurations have been made, servers are managed through the Provisioning Services Console.


A store is the logical name for the physical location of the vDisk folder. This folder can exist on a local server or on shared storage. When vDisks files are created in the Console, they are assigned to a store. Within a site, one or more Provisioning Servers are given permission to access that store in order to serve vDisks to target devices.

A Provisioning Server checks the database for the Store name and the physical location where the vDisk resides, in order to provide it to the target device

Separating the physical paths to a vDisks storage locations allows for greater flexibility within a farm configuration, particularly if the farm is configured to be highly available. In a highly available implementation, if the active Provisioning Server in a site fails, the target device can get its vDisk from another Provisioning Server that has access to the store and permissions to serve the vDisk.

Device Collections: 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.

Note: A target device can only be a member of one device collection.

A device collection could represent a physical location, a subnet range, or a logical grouping of target devices.

Target Devices:

A device, such as desktop computer or server, that boots and gets software from a vDisk on the network, is considered a target device. A device that is used to create the vDisk image is a considered a Master Target device.

The lifecycle of a target device includes:

  • Preparing
    • A Master target device used for creating a vDisk image
    • A target device that will boot from a vDisk image
  • Adding target devices to a collection in the farm
    • From the Console
    • Using Auto-Add
    • Importing
  • Assigning the target device type
  • Maintaining target devices in the farm

After a target device is created, the device must be configured to boot from the network, the device itself must be configured to allow it to boot from the network, a vDisk must be assigned to the device, and a bootstrap file must be configured to provide the information necessary for that device to boot from the assigned vDisk.


These are the actual VHDX files which contain operating system. vDisks are managed throughout the vDisk lifecycle. Full image lifecycle takes a vDisk from initial creation, through deployment and subsequent updates, and finally to retirement. The lifecycle of a vDisk consists of four stages:

  1. Creating
  2. Deploying
  3. Updating
  4. Retiring

After a vDisk base image is created, it is deployed by assigning it to one or more devices. A device can have multiple vDisk assignments. When the device starts, it boots from an assigned vDisk. There are two boot mode options; Private Image mode (single device access, read/write), and Standard Image mode (multiple devices, write cache options).


Provisioning Server provides a Printer Management feature that allows you to manage which printers target devices have access to on a vDisk. Printers are managed from the Target Device Properties dialog, in vDisks page.

This feature should not be enabled if you use Active Directory to manage printers. If you use an existing printer management tool, this feature should be disabled to avoid printer setting conflicts.


The Console View provides a method that allows you to quickly manage a group of devices. Views are typically created according to business needs. For example, a view can represent a physical location, such as a building or user type. Unlike device collections, a target device can be a member of any number of views.

Farm administrators can create and manage views in the Console tree’s Farm > Views folder. Farm views can include any target device that exists in this farm. Site administrators can create and manage views in the Console tree’s Farm > Sites > YourSite > Views folder. Site views can only include target devices that exist within that site (YourSite).

Power Rating:

Power rating with lowest value will get low number of vms. If power rating is 2 for server A and 1 for server B, Server A will get twice number of VDIs than Server B. You should change power rating only if you have different hardware versions for PVS servers.


Each machine will have a Write Cache location assigned to it where all the writes to the (read-only) vDisk will be stored. The _write cache_includes data written by the target device. However, vDisks can also be assigned in a one-to-one fashion, which is referred to as Private Image Mode, allowing the user to read and write to the vDisk. All changes made will be saved.

When vDisk is in Standard mode, we cannot update any files in that vDisk as it is in read-only mode. So, all the temp data is written to write cache location. This write cache could be a automatically generated log file, or a file that user modified, or temp files in OS, or any information during a vDisk connection.

From Carl websters’ site:



PVS Farm

A collection of PVS servers that share a common database.  The database contains all the configuration information.  A farm represents the top level of the PVS infrastructure.  A farm provides a way to represent, define and manage logical groups of PVS servers into sites.


Provides a way to represent and manage logical groups of PVS servers, Device Collections and local shared storage.  A PVS site does not necessarily have anything to do with either an Active Directory site or a XenApp zone.

Device Collection

Provides the ability to create and manage logical groups of target devices.

Target Device

Any device, physical or virtual, that boots and receives software from a vDisk stored on the network in a store.


A logical name given to the physical vDisk storage location.


vDisks exists as disk image files on a PVS server or on a shared storage device.  A vDisk consists of a VHD file and there may be other associated files.


“Retry” definition: The client’s driver performs a vDisk I/O by sending a request to the Provisioning Server. If a transaction fails because of a timeout (which is a no-reply timeout), the driver tries to receive the packet again. The retry number is accumulated by the client and reported to the client’s statistics tray.

Retries in PVS are a mechanism to track packet drops in the streaming traffic between a Provisioning Server and a target device.

Solution for high retries is to disable tcpoffload.

Want to learn more on Citrix Automations and solutions???

Subscribe to get our latest content by email.

If you like our content, please support us by sponsoring on GitHub below: