Collections of physical or virtual machines are managed as a single entity called a Machine Catalog. All of the machines in a Machine Catalog have the same type of operating system: server or desktop. A catalog containing server OS machines can contain either Windows or Linux machines, not both.
Studio guides you to create the first Machine Catalog after you create the Site. After you create the first Machine Catalog, Studio guides you to create your first Delivery Group. Later, you can change the catalog you created, and create more catalogs.
When you create a catalog that will contain VMs, you specify how those VMs will be provisioned: you can use tools supported by Studio, such as Machine Creations Services (MCS) or Provisioning Services, or you can use your own tools to provide machines. If your machines are already provided for you (so you do not need to use master images), you still create one or more Machine Catalogs for your machines.
- If you are using Provisioning Services to create machines, see the Provisioning Services documentation for instructions.
- If you choose MCS to provision VMs, you provide a master image (or snapshot) as a guide to create identical VMs in the catalog. Before you create the catalog, you first use tools on your hypervisor or cloud service to create and configure the master image - this includes installing a Virtual Delivery Agent (VDA) on the image. Then, when you create the Machine Catalog in Studio, you select that image (or a snapshot of it), specify the number of VMs to create in the catalog, and configure additional information.
When using MCS or PVS to create your first Machine Catalog, you use the host connection that you configured when you created the Site. Later (after you create your first Machine Catalog and Delivery Group), you can change information about that connection or create additional connections.
After you complete the Machine Catalog creation wizard, tests run automatically to ensure that it is configured correctly. When the tests complete, you can view a test report. Later, you can run the tests at any time from Citrix Studio site-name in the Studio navigation pane.
Tip: If you are creating a catalog using the PowerShell SDK directly, rather than Studio, you can specify a hypervisor template (VMTemplates), as an alternative to an image or a snapshot of an image.
If you have Windows XP or Windows Vista machines, they must use an earlier VDA version, and will not be able to use the latest product features. If you cannot upgrade those machines to a supported Windows operating system version, Citrix recommends you keep them in a separate Machine Catalog.
MCS catalog creation summary
Here's a brief overview of MCS actions after you provide information in the Create Machine Catalog wizard.
- If you selected a master image (rather than a snapshot) in the wizard, MCS creates a snapshot.
- MCS creates a full copy of the snapshot and places this on each storage location defined in the host connection.
- MCS adds the desktops to Active Directory, which creates unique identities.
- MCS creates the number of VMs specified in the wizard, with two disks defined for each VM. In addition to the two disks per VM, a master is also stored in the same storage location. If you have multiple storage locations defined, each gets the following disk types:
- The full copy of the snapshot (noted above), which is read-only and shared across the VMs just created.
- A unique 16 MB identity disk that gives each VM a unique identity. Each VM gets an identity disk.
- A unique difference disk to store writes made to the VM. This disk is thin provisioned (if supported by the host storage) and increases to the maximum size of the master image, if required. Each VM gets a difference disk. This is the disk that holds changes made during sessions - it is permanent for dedicated desktops; for pooled desktops, it is deleted and a new one created after each restart.
Prepare a master image on the hypervisor or cloud service
Tip: For information about creating connections to hypervisors and cloud providers, see the Connections and resources article.
The master image contains the operating system, non-virtualized applications, VDA, and other software.
Good to know:
- A master image might also be known as a clone image, golden image, base VM, or base image. Host vendors and cloud service providers may use different terms.
- When using Provisioning Services, you can use a master image or a physical computer as the master target device. Provisioning Services uses different terminology than MCS to refer to images; see its documentation for details.
- Make sure your host has sufficient processors, memory, and storage to accommodate the number of machines you will create.
- Configure the correct amount of hard disk space required for desktops and applications, because that value cannot be changed later or in the Machine Catalog.
- Remote PC Access Machine Catalogs do not use master images.
- Microsoft KMS activation considerations when using MCS:If your deployment includes 7.x VDAs with a XenServer 6.1 or 6.2, vSphere, or Microsoft System Center Virtual Machine Manager host, you do not need to manually re-arm Microsoft Windows or Microsoft Office. If your deployment includes a 5.x VDA with a XenServer 6.0.2 host, see CTX128580.
- Install and configure the following software on the master image:
- Integration tools for your hypervisor (such as XenServer Tools, Hyper-V Integration Services, or VMware tools). If you omit this step, your applications and desktops might not function correctly.
- A VDA - Citrix recommends installing the latest version to allow access to the newest features. Failure to install a VDA on the master image will cause the catalog creation to fail.
- Third-party tools as needed, such as anti-virus software or electronic software distribution agents. Configure services with settings that are appropriate for users and the machine type (such as updating features).
- Third-party applications that you are not virtualizing. Citrix recommends virtualizing applications because it significantly reduces costs by eliminating the need to update the master image after adding or reconfiguring an application. In addition, fewer installed applications reduce the size of the master image hard disks, which saves storage costs.
- App-V clients with the recommended settings, if you plan to publish App-V applications. The App-V client is available from Microsoft.
- When using MCS, and you will localize Microsoft Windows, install the locales and language packs. During provisioning, when a snapshot is created, the provisioned VMs use the installed locales and language packs.
Important: If you are using Provisioning Services or MCS, do not run Sysprep on master images.
To prepare a master image:
- Using your hypervisor’s management tool, create a new master image and then install the operating system, plus all service packs and updates. Specify the number of vCPUs (you can also specify this value when you create the Machine Catalog, but only when using PowerShell; you cannot specify the number of vCPUs in the Studio user interface when creating a catalog). Be sure to configure the amount of hard disk space required for desktops and applications, because that value cannot be changed later or in the Machine Catalog.
- Make sure that the hard disk is attached at device location 0. Most standard master image templates configure this location by default, but some custom templates may not.
- Install and configure the software listed above on the master image:
- When using Provisioning Services, create a VHD file for the vDisk from your master target device before you join the master target device to a domain. See the Provisioning Services documentation for details.
- Join the master image to the domain where applications and desktops will be members, and make sure that the master image is available on the host where the machines will be created. Note that joining the master image to a domain is not required if you are using MCS: the provisioned machines are joined to the domain specified in the Create Machine Catalog wizard.
- Citrix recommends that you create and name a snapshot of your master image so that it can be identified later. If you specify a master image rather than a snapshot when creating a Machine Catalog, Studio creates a snapshot, but you cannot name it.
Prepare a master image for GPU-capable machines on XenServer
When using XenServer for your hosting infrastructure, GPU-capable machines require a dedicated master image. Those VMs require video card drivers that support GPUs, and must be configured to allow the VM to operate with software that uses the GPU for operations.
- In XenCenter, create a VM with standard VGA, networks, and vCPU.
- Update the VM configuration to enable GPU use (either Passthough or vGPU).
- Install a supported operating system and enable RDP.
- Install XenServer Tools and NVIDIA drivers.
- Turn off the Virtual Network Computing (VNC) Admin Console to optimize performance, and then restart the VM.
- You are prompted to use RDP. Using RDP, install the VDA and then restart the VM.
- Optionally, create a snapshot for the VM as a baseline template for other GPU master images.
- Using RDP, install customer-specific applications that are configured in XenCenter and use GPU capabilities.
Create a Machine Catalog using Studio
Before you start the Machine Catalog creation wizard, review this section to learn about the choices you will make and information you will supply. When you start the wizard, some of the pages described below may not appear or they may have different titles, based on the selections you make.
Important: If you are using a master image, make sure you have installed a VDA on the image before creating the Machine Catalog.
- If you have created a Site but haven’t yet created a Machine Catalog, Studio will guide you to the correct starting place to create a Machine Catalog.
- If you have already created a Machine Catalog and want to create another, select Machine Catalogs in the Studio navigation pane, and then select Create Machine Catalog in the Actions pane.
The wizard walks you through the items described below. The wizard pages you see may differ, depending on selections you make.
Each catalog contains machines of only one type:
- Server OS: A Server OS catalog provides desktops and applications that can be shared by multiple users. The machines can be running supported versions of the Windows or Linux operating systems, but the catalog cannot contain both.
- Desktop OS: A Desktop OS catalog provides desktops and applications that are assigned to a variety of different users.
- Remote PC Access: A Remote PC Access catalog provides users with remote access to their physical office desktop machines. Remote PC Access does not require a VPN to provide security.
The Machine Management page indicates how machines are managed and which tool you will use to deploy machines.
Choose whether or not machines in the catalog will be power managed through Studio.
- Machines are power managed through Studio or provisioned through a cloud environment, for example, VMs or blade PCs. This option is available only if you have a connection to a hypervisor or cloud service already configured.
- Machines are not power managed through Studio, for example, physical machines.
If you indicated that machines are power managed through Studio or provisioned through a cloud environment, choose which tool you will use to deploy machines.
- Machine Creation Services (MCS) – Uses a master image to create and manage virtual machines. Machine Catalogs in cloud environments use MCS. MCS is not available for physical machines.
- Provisioning Services – Manages target devices as a device collection. A Provisioning Services vDisk imaged from a master target device delivers desktops and applications. This option is not available for cloud deployments.
- Other – A tool that manages machines already in the data center. Citrix recommends you use Microsoft System Center Configuration Manager or another third-party application to ensure that the machines in the catalog are consistent.
Desktop types (desktop experience)
The Desktop Experience page (which appears only when creating a catalog containing Desktop OS machines) determines the type of desktops that will be created. The types differ according to whether or not they are assigned to a user, and what happens to any changes the user made when the machine restarts.
There are three types:
- Pooled, random: Desktops are assigned randomly – users connect to a new (random) desktop each time they log on. When a user logs off, the desktop becomes available for another user. When the desktop is restarted, any changes that were made are discarded.
- Pooled, static: Desktops are permanently assigned – users connect to the same (static) desktop each time they log on. When that user logs off, the desktop remains available only for that user. When the desktop is restarted, any changes that were made are discarded.
- Dedicated: Desktops are permanently assigned to a user. When that user logs off, the desktop remains available only for that user. When the desktop is restarted, any changes that were made are retained. You can save changes to a local VM disk or to a specified drive letter on a separate Personal vDisk.
Select the connection to the host hypervisor or cloud service, and then select the snapshot or VM created earlier. If you are creating the first Machine Catalog, the only available connection will be the one you configured when you created the Site.
- If you are using Provisioning Services or MCS, do not run Sysprep on master images.
- If you specify a master image rather than a snapshot, Studio creates a snapshot, but you cannot name it.
To ensure you can use the latest product features, make sure the master image has the latest VDA version installed. Do not change the default Select the VDA version installed selection on the wizard page.
An error message appears if you select a snapshot or VM that is not compatible with the machine management technology you selected earlier in the wizard.
Security (cloud service environments)
Select one or more security groups for the VMs; these are shown only if the availability zone supports security groups.
Choose whether machines will use shared hardware or account-dedicated hardware.
Virtual machines, device collection, or VMs and users
The title of this page depends on the deployment method you chose on the Machine Management page.
- If you chose MCS, this page is titled Virtual Machines.
- If you chose Provisioning Services, this page is titled Device Collection.
- If you chose Other tools, this page is titled VMs and users.
On this page:
- Specify how many virtual machines to create.
- Choose the amount of memory (in MB) each machine will have.
- If you indicated on the Desktop Experience page that user changes to dedicated desktops should be saved on a separate Personal vDisk, specify the vDisk size in gigabytes and the drive letter.
- If your deployment contains more than one zone, you can select a zone for the catalog.
- If you are using MCS to deploy machines and creating pooled random VMs that do not use personal vDisks, you can configure a cache to be used for temporary data on each machine. For details, see the following section.
Important: Each VM will have a hard disk. Its size is set in the master image; you cannot change the hard disk size in the catalog.
Configure cache for temporary data
Caching temporary data locally on the VM is optional. You can enable use of the temporary data cache on the machine when you use MCS to manage pooled (not dedicated) machines in a catalog. If the catalog uses a connection that specifies storage for temporary data, you can enable and configure the temporary data cache information when you create the catalog.
To enable the caching of temporary data, the VDA on each machine in the catalog must be minimum version 7.9.
You specify whether temporary data uses shared or local storage when you create the connection that the catalog uses; for details, see the Connections and resources article. Enabling and configuring the temporary cache in the catalog includes two check boxes and values: Memory allocated to cache (MB) and Disk cache size (GB). The default values differ according to the connection type. Generally, the default values are sufficient for most cases; however, take into account the space needed for:
- Temporary data files created by Windows itself, including the Windows page file.
- User profile data.
- ShareFile data that is synced to users' sessions.
- Data that may be created or copied by a session user or any applications users may install inside the session.
Windows will not allow a session to use an amount of cache disk that is significantly larger than the amount of free space on the original master image from which machines in the Machine Catalog are provisioned. For example, there is no benefit specifying a 20 GB cache disk if there is only 10 GB of free space on the master image.
If you enable the Disk cache size check box, temporary data is initially written to the memory cache. When the memory cache reaches its configured limit (the Memory allocated to cache value), the oldest data is moved to the temporary data cache disk.
The memory cache is part of the total amount of memory on each machine; therefore, if you enable the Memory allocated to cache check box, consider increasing the total amount of memory on each machine.
If you clear the Memory allocated to cache check box and leave the Disk cache size check box enabled, temporary data is written directly to the cache disk, using a minimal amount of memory cache.
Changing the Disk cache size from its default value can affect performance. The size must match user requirements and the load placed on the machine.
Important: If the disk cache runs out of space, the user's session becomes unusable.
If you clear the Disk cache size checkbox, no cache disk will be created. In this case, specify a Memory allocated to cache value that is large enough to hold all of the temporary data; this is feasible only if large amounts of RAM are available for allocation to each VM.
If you clear both check boxes, temporary data is not cached; it is written to the difference disk (located in the OS storage) for each VM. (This is the provisioning action in releases earlier than 7.9.)
Caching should not be enabled if you intend to use this catalog to create AppDisks.
You cannot change the cache values in a Machine Catalog after it is created.
Network Interface Cards (NICs)
If you plan to use multiple NICs, associate a virtual network with each card. For example, you can assign one card to access a specific secure network, and another card to access a more commonly-used network. You can also add or remove NICs from this page.
(Valid only for Remote PC Access catalogs) Specify the Active Directory machine accounts or Organizational Units (OUs) to add that correspond to users or user groups. Do not use a forward slash (/) in an OU name.
You can choose a previously-configured power management connection or elect not to use power management. If you want to use power management but a suitable connection hasn't been configured yet, you can create that connection later and then edit the Machine Catalog to update the power management settings.
Each machine in the catalog must have a corresponding Active Directory computer account. Indicate whether to create new accounts or use existing accounts, and the location for those accounts.
- If you create new accounts, you must have access to a domain administrator account for the domain where the machines will reside.
Specify the account naming scheme for the machines that will be created, using hash marks to indicate where sequential numbers or letters will appear. Do not use a forward slash (/) in an OU name. A name cannot begin with a number. For example, a naming scheme of PC-Sales-## (with 0-9 selected) results in computer accounts named PC-Sales-01, PC-Sales-02 , PC-Sales-03, and so on.
- If you use existing accounts, either browse to the accounts or click Import and specify a .csv file containing account names. The imported file content must use the format:
Make sure that there are enough accounts for all the machines you’re adding. Studio manages these accounts, so either allow Studio to reset the passwords for all the accounts or specify the account password, which must be the same for all accounts.
For catalogs containing physical machines or existing machines, select or import existing accounts and assign each machine to both an Active Directory computer account and to a user account.
For machines created with Provisioning Services, computer accounts for target devices are managed differently; see the Provisioning Services documentation.
On the Summary page of the wizard, review the settings you specified. Enter a name and description for the catalog; this information appears in Studio.
After reviewing the information you specified, click Finish to start the catalog creation.