“We Train, You Succeed: Trusted by Thousands for Training & Placement”. Know more!

Call us @ 9666019191

HomeCitrixCitirx MCS Process

Citirx MCS Process

Citrix MCS (Machine Creation Services) is a provisioning technology in Citrix Virtual Apps and Desktops (formerly XenDesktop) that simplifies the creation, management, and updating of virtual machine (VM) images.

Key Features of Citrix MCS:

  1. Automated VM Provisioning:
    1. MCS automates the process of deploying multiple virtual desktops or servers by creating a golden image (Master VM) and provisioning multiple clones from it.
  2. Storage Optimization:
    1. MCS uses differencing disks, meaning it only stores changes made to each VM from the golden image, which saves significant storage space.
  3. Image Management:
    1. You can easily update the base image (Master VM) and then propagate those changes across all the machines linked to that image with minimal downtime.
  4. Snapshot and Delta Technology:
    1. MCS uses snapshot-based technology, creating a “base disk” (from the master VM) and layering it with delta disks that store the changes made by users. This provides flexibility and reduces the storage overhead.
  5. Scalability:
    1. MCS can create and manage thousands of VMs with ease, whether on-premise or in the cloud (e.g., using Azure or AWS for Citrix Cloud deployments).
  6. Hypervisor Support:
    1. MCS supports multiple hypervisors, including Citrix Hypervisor (formerly XenServer), VMware ESXi, Microsoft Hyper-V, and cloud platforms such as AWS and Azure.
  7. Deployment Types:
    1. You can deploy both persistent and non-persistent desktops with MCS.
      1. Persistent: Users retain their data and configurations across sessions.
      1. Non-persistent: VMs reset to the base image after each session to ensure a consistent user experience.
  8. Power Management:
    1. MCS can automatically power on and off VMs depending on user demand, saving resources during off-peak times.
  9. Integration with Citrix Studio:
    1. Administrators can easily manage MCS from Citrix Studio, making it simple to create machine catalogs and manage updates without needing deep infrastructure knowledge.
  10. Cloud Support:
    1. Citrix MCS supports Citrix Cloud environments, allowing organizations to manage hybrid or cloud-only deployments seamlessly.

Workflow for MCS:

  1. Create a Master Image:
    1. A master virtual machine with the operating system, necessary applications, and settings is created.
  2. Snapshot the Master VM:
    1. A snapshot is taken of the master image, which becomes the template for creating the other VMs.
  3. Provision Machines:
    1. MCS clones the master image and uses storage optimization techniques to deploy virtual desktops or servers to users, utilizing linked clones to minimize the storage impact.
  4. Update and Maintenance:
    1. When an update is needed (like a software patch), the administrator updates the master image, takes a new snapshot, and propagates the changes across all the VMs linked to that master image.

Advantages of Citrix MCS:

  • Simplified management for administrators with minimal infrastructure overhead.
  • Efficient storage usage due to the use of base images and differencing disks.
  • Quick deployment of virtual desktops and applications.
  • Flexibility in supporting both persistent and non-persistent environments.

Advantages and Disadvantages of Citrix MCS (Machine Creation Services)


Advantages:

  1. Simplified Image Management:
    1. MCS simplifies the process of deploying and managing virtual machines by using a single master image. Administrators can easily update the master image and propagate changes across all linked machines.
  2. Storage Efficiency:
    1. MCS uses differencing disks, meaning it only stores changes made to individual machines, reducing the amount of storage required for a large number of virtual machines. This is especially beneficial for environments with limited storage resources.
  3. Quick VM Provisioning:
    1. MCS enables fast creation and deployment of virtual desktops and servers from a base image, which saves time compared to manually configuring each VM.
  4. Automation:
    1. The entire VM provisioning process is automated, from creating VMs to managing power states, leading to less manual intervention and improved operational efficiency.
  5. Support for Multiple Hypervisors:
    1. MCS works with a range of hypervisors such as Citrix Hypervisor, VMware ESXi, Microsoft Hyper-V, and public cloud platforms like AWS and Azure, giving flexibility in deployment.
  6. Scalability:
    1. MCS can scale easily, allowing administrators to provision hundreds or thousands of virtual desktops in both on-premise and cloud environments. It’s ideal for large organizations or enterprises with growing user bases.
  7. Non-Persistent and Persistent Desktops:
    1. MCS supports both non-persistent (reset to the base image after each session) and persistent desktops (users retain data and settings across sessions), offering flexibility based on different use cases.
  8. Seamless Updates:
    1. Updates to the base image can be rolled out easily by updating the master VM and propagating those updates across the VMs without needing to recreate them from scratch.
  9. Cost-Effective Cloud Deployments:
    1. In cloud environments like Azure or AWS, MCS optimizes costs by enabling administrators to scale resources on-demand and power off VMs during off-peak hours.

Disadvantages:

  1. Performance Bottlenecks:
    1. Since MCS uses differencing disks (snapshots of the base image), the performance of the virtual machines can degrade over time, especially in write-heavy environments or if snapshots are not managed effectively.
  2. No Provisioning Across Multiple Storage Locations:
    1. MCS does not support creating VMs across multiple storage locations. This can limit flexibility in large environments that rely on multiple storage systems for load distribution.
  3. Dependency on Citrix Infrastructure:
    1. MCS requires integration with Citrix infrastructure, such as Delivery Controllers and Citrix Studio, which may not suit organizations without existing Citrix investments.
  4. Lack of Granular Control:
    1. Compared to Provisioning Services (PVS), which offers more fine-grained control over the virtual machines and streaming of VMs, MCS may be seen as limited in terms of customization and flexibility for specific scenarios.
  5. Storage Overhead with Full Clones:
    1. If an organization requires persistent desktops where each user has their own dedicated virtual machine, MCS might not be as storage-efficient because each user’s data must be stored separately (full clones), which increases storage overhead.
  6. Latency in Updates:
    1. When an update to the master image is needed, MCS requires the VMs to reboot to receive the new image, leading to potential downtime or disruption to the end-users, especially in time-sensitive environments.
  7. Limited Advanced Features:
    1. MCS lacks some of the advanced features found in Provisioning Services (PVS), such as streaming the operating system over the network, which can be beneficial for large-scale, stateless desktop environments.
  8. Resource Consumption During Boot Storms:
    1. In scenarios where many VMs are started simultaneously (e.g., during a boot storm in the morning), there can be increased demand on the storage system, leading to potential performance degradation if not properly managed.

Comparison with Citrix Provisioning Services (PVS):

  • MCS is easier to set up and manage, making it suitable for smaller to medium-sized environments or for organizations looking for quick and simple VM provisioning.
  • PVS offers more advanced features, such as streaming OS images over the network and more control over the virtual environment but is more complex to deploy and manage.

Best Use Cases for MCS:

  • Small to medium-sized environments where simplicity and speed are prioritized.
  • Non-persistent virtual desktops where data does not need to be saved after each session.
  • Organizations looking to integrate virtual desktops into cloud environments (Azure or AWS).

Citrix MCS vs. Citrix PVS: A Detailed Comparison

Citrix provides two main technologies for provisioning virtual desktops and servers: Machine Creation Services (MCS) and Provisioning Services (PVS). While both serve similar purposes—automating the deployment and management of virtual machines (VMs)—they are fundamentally different in how they operate and are best suited for different use cases.


Overview of Citrix MCS (Machine Creation Services):

  • How it works: MCS creates full clones or linked clones from a master image (snapshot) and provisions multiple virtual machines from this image. These VMs then operate on their own but reference the master image for shared data. MCS can work in both cloud environments and on-premise infrastructure.
  • Provisioning model: Disk-based cloning from a master image.
  • Target environments: Simpler, smaller deployments and cloud-based VDI.
  • Key Benefits: Simplicity, cloud support, integration with multiple hypervisors.
  • Main Drawback: Potential storage bottlenecks, especially with persistent desktops.

Overview of Citrix PVS (Provisioning Services):

  • How it works: PVS streams the operating system (OS) and applications to virtual or physical machines directly over the network. It delivers stateless desktops by streaming a single shared image (vDisk) to all virtual desktops, which boot from this shared image in real-time.
  • Provisioning model: Network-based streaming of OS and apps.
  • Target environments: Large, complex, or stateless desktop environments with high scalability requirements.
  • Key Benefits: High scalability, advanced control, more efficient storage utilization.
  • Main Drawback: More complex to set up and manage, requires a robust network.

1. Provisioning Approach:

  • MCS:
    • Uses disk-based snapshots and cloning to create VMs.
    • Deploys linked clones (differencing disks) or full clones, depending on the environment.
    • Storage is a key factor, as MCS stores a base image and generates small differencing disks for each VM.
  • PVS:
    • Streams a single shared vDisk image over the network to multiple VMs.
    • Stateless provisioning—since the operating system and applications are streamed to the machine every time it boots, no data is saved locally.

Key Difference:

  • MCS uses disk-based provisioning, whereas PVS uses network-based streaming.

2. Performance:

  • MCS:
    • MCS performance is tied to the speed and efficiency of the storage system. Over time, as differencing disks grow and VMs accumulate data, MCS performance can degrade, especially in write-intensive environments.
    • Boot storms (when many VMs start simultaneously) can stress storage resources.
  • PVS:
    • PVS delivers high performance since it streams the OS over the network. It’s particularly efficient for stateless desktops, where machines can be booted from a single shared image.
    • Performance depends on the network infrastructure—poor network setup can cause bottlenecks.

Key Difference:

  • MCS can experience storage bottlenecks, while PVS requires a robust network to function at peak efficiency.

3. Scalability:

  • MCS:
    • Suitable for small to medium environments, or cloud deployments where storage resources are more flexible.
    • Easy to scale, but the storage infrastructure may limit the upper scalability depending on the number of VMs.
  • PVS:
    • Built for large-scale environments. Since PVS streams the OS to each VM, it scales very efficiently with less demand on storage.
    • Can handle thousands of machines with ease, especially in environments where stateless desktops are a priority.

Key Difference:

  • MCS is ideal for smaller to medium deployments; PVS excels in large, high-scale deployments.

4. Management Complexity:

  • MCS:
    • Easier to set up and manage. It’s built into Citrix Studio, with a user-friendly interface and fewer components to configure.
    • Ideal for organizations with limited Citrix expertise or smaller teams managing VDI environments.
  • PVS:
    • More complex to configure and manage. PVS involves setting up provisioning servers, network configurations, and vDisks.
    • Requires a deeper understanding of Citrix infrastructure and network management, making it more suitable for environments with a dedicated IT team.

Key Difference:

  • MCS offers simplicity in management, while PVS requires advanced configuration and expertise.

5. Storage Efficiency:

  • MCS:
    • While MCS uses differencing disks to reduce storage consumption, the storage demands increase as persistent desktops grow or when many full clones are used.
    • More storage-intensive for persistent desktops or in environments where each VM needs significant disk space.
  • PVS:
    • PVS is extremely efficient with storage, as it streams the OS from a single vDisk. The storage requirement is significantly reduced since the OS and applications do not need to be duplicated across multiple VMs.
    • Stateless desktops consume very little storage locally, and PVS eliminates the need for maintaining multiple copies of the OS.

Key Difference:

  • PVS is more storage-efficient than MCS, especially for stateless or non-persistent environments.

6. Flexibility:

  • MCS:
    • Works well with both persistent and non-persistent desktops, allowing users to retain data across sessions if needed.
    • Supported across multiple hypervisors (Citrix Hypervisor, VMware, Hyper-V) and integrates seamlessly with cloud providers like AWS and Azure.
  • PVS:
    • Primarily designed for non-persistent desktops, where machines are stateless and revert to their original state after each reboot.
    • It’s less flexible in environments that require persistent desktops, as PVS is optimized for streaming a single shared image.

Key Difference:

  • MCS is more versatile (supporting both persistent and non-persistent desktops), while PVS is more suited for stateless desktops.

7. Cost:

  • MCS:
    • Typically lower costs upfront due to its simpler setup and fewer infrastructure requirements (e.g., no need for dedicated provisioning servers).
    • May incur higher storage costs over time, especially in persistent desktop environments where full clones are required.
  • PVS:
    • Higher initial cost due to the complexity of setup and the need for provisioning servers.
    • More cost-efficient over time in terms of storage savings and management in large environments, as it scales more efficiently.

Key Difference:

  • MCS tends to be less costly upfront but may have higher storage costs in the long run. PVS requires higher initial investment, but scales more cost-efficiently.

When to Use MCS vs. PVS:

When to Choose MCS:

  • Smaller to medium environments.
  • Cloud-based VDI deployments (AWS, Azure).
  • Organizations looking for ease of management.
  • Environments where both persistent and non-persistent desktops are required.

When to Choose PVS:

  • Large-scale environments with thousands of VMs.
  • Stateless, non-persistent desktops where storage efficiency and performance are key.
  • Organizations with robust network infrastructure and Citrix expertise.
  • Scenarios where minimal local storage per VM is a priority.

Conclusion:

  • MCS is ideal for organizations looking for a simple, quick-to-deploy solution with moderate scalability and support for both persistent and non-persistent desktops.
  • PVS excels in environments where high scalability, network-based streaming, and stateless desktops are critical, though it requires a more robust infrastructure and expertise.

Would you like more information on configuring MCS or PVS? Or perhaps a deeper dive into one of the specific technologies?

Top of Form

Bottom of Form

MCS High-level VM and Disk Architecture

The first step when using Citrix MCS is to provision a master VM that serves as a template to create clones. The IT administrator can provision the VM with the required amount of CPU, RAM and disk space, and then install an operating system and required applications. Using the Citrix Studio Console, the admin creates a machine catalog of clone VMs using the base image. Those VMs live in a data store, which is different from PVS.

Citrix MCS is completely relying on storage. When the VM is provisioned two types of disks are created for each VM: a differencing disk and an identity disk.

Citrix MCS creates the number of VMs specified in the create catalog wizard with two disks defined for each VM on the storage. A copy of the master image is also stored in the same storage repository. If there are multiple storage repositories defined, then each one gets the following types of disks.

Each storage repository gets one full snapshot of the master VM image, which is read-only and shared across the VMs.

A unique identity disk (16 MB) for VM identity will also be created. The Delivery Controller creates the identity disks for each VM.

Each VM also gets a difference disk. A unique difference disk used to store any writes made to the VM. The disk is thin provisioned (if supported by the storage) and will increase to the maximum size of the base disk if necessary.

Full Clone

Sometimes, it is not desirable to create VMs with delta disks. A few reasons are mentioned below:

  • Some of the backup solutions don’t backup VMs that contain a delta structure
  • Storage migration becomes more complicated
  • VM migration does not work on all hypervisors
  • Deltas grows over time which leads to load on storage

For these reasons, MCS added a new capability in addition to creating the existing delta structure called full clones. When using persistent VMs, Citrix MCS allows admins to select VMs to be created with a full clone of the master image.

There is no special requirement for full clones. Citrix MCS uses its identity technology to change the identity of the full clone. Full clone machines have two disks, one for the actual VM, and one for identity including machine name, computer account and password. Full clone VMs can be moved to a different datastore or cluster which is not possible with linked clones.

While provisioning machines through Citrix Studio, full clones is only an option for desktop OS and not for server OS. To create server OS full clones using MCS use PowerShell. Guidance on how to use PowerShell for this process is found in CTX277484.

Machine Catalog

Collections of physical or virtual machines are managed as a single entity called a Machine Catalog in Citrix environments. While creating Machine Catalogs administrators have the option to select ways to provision VMs, and which Citrix image management tools such as Citrix Machine Creation Services or Provisioning Services.

Reference: Citrix docs: Machine Catalogs

Host Connection

In Citrix Virtual Apps and Desktops, before creating the machine catalog it is important to create connections to hosting resources while creating a site to integrate an underlying platform including hypervisor or cloud providers. Configuring a connection includes selecting the connection type among the supported hypervisors and cloud services. The system requirements page lists the supported hypervisors and cloud options.

Reference: Citrix docs: System requirements

Host storage

A storage product is supported if it can be managed by a supported hypervisor. Provisioning machines, data is classified by type:

  • Operating system (OS) data, which includes master images
  • Temporary data, which include all non-persistent data written to MCS-provisioned machines, Windows page files, user profile data, and any data that is synchronized with Content Collaboration (formerly ShareFile). This data is discarded each time the machine restarts

Provisioning separate storage for each data type can reduce load and improves IOPS performance on each storage device.

Storage shared by hypervisors

Shared storage stores data that is retained for longer periods and provides centralized backup and management. This storage holds the OS disks and other disks associated with virtual machines. When using shared storage, local storage to the hypervisor used for temporary data cache, aids to reduce traffic for main OS storage. The disk is cleared after every machine restart, using local storage for temporary data. The provisioned VDA is tied to a specific hypervisor host. If the host goes down, the VM cannot start.

The hypervisor provides optimization technologies through read caching of the disk images locally. For example, Citrix Hypervisor (formerly XenServer) offers IntelliCache. This reduces network traffic to the central storage.

Citrix Hypervisor also supports read caching using the host’s free memory. The performance improvement can be seen whenever data is read from disk more than once, as it gets cache in memory.

Both read-caching and IntelliCache can be enabled simultaneously. In this case, IntelliCache caches the reads from the network to a local disk. Reads from that local disk are cached in memory with read caching.

Reference: Citrix docs: storage read-caching

Local storage

Local storage stores data locally on the hypervisor local data store. This includes, master images and other OS data that are, transferred to all of the hypervisors in the site. This method increases network traffic along with management traffic.

When this method is selected, the option to choose whether to use shared storage to provide resilience and support for backup and disaster recovery systems is available.

How MCS works with on-premises hypervisors

Below is the pictorial flow diagram and workflow depicting how Citrix Machine Creation Services works with on-premises hypervisors.

Citrix Machine Creation Services uses hypervisor APIs to provision virtual machines. Each virtual machine is assigned an identity disk that gives the machine a unique identity and a differencing disk that handles the writes for the virtual machine.

Instruction Disk: This small instruction disk contains the steps of the image preparation to run and is attached to that VM. The preparation virtual machine is then started, the image preparation process begins, and the virtual machine is shut down.

Identity Disk: A unique Identity Disk used to provide each virtual machine with a unique identity. The functionality within the Delivery Controller creates the identity Disks. This disk is 16 MB in size.

Differencing Disk: A unique Difference Disk is used to store any writes made to the VM. The disk is thin provisioned and will increase to the maximum size of the base VM as required.

Cache for Temporary Data

For the pooled (not dedicated) machines in a machine catalog, administrators can enable the use of temporary data cache on the machine. To enable this feature, the VDA on each machine in the catalog must be minimum version 7.9 and above. This feature is also referred to as MCS-IO.

The administrator must specify the storage type for temporary data that the catalog uses. Enabling temporary cache in the catalog includes Memory allocated to Cache (MB) and Disk cache size (GB).

  • The temporary data is written to the memory cache until it reaches the limit, when the temporary data reaches the configured limit, the cold data is moved to temporary data cache disk.
  • Memory cache is part of total memory on each machine, before enabling this option, consider increasing the total amount of memory of each machine.
  • Enabling only disk cache size, temporary data is written directly to the cache disk, using a minimal amount of memory cache.
  • Disabling both options, temporary data is not cached and it is written to the differencing disk of each VM.

Citrix MCS with Linux VDAs

Citrix Machine Creation Services offers administrators the ability to create Linux VMs starting from Citrix XenApp and XenDesktop 7.18 and later. Prepare a master virtual machine on the hypervisor or cloud provider and install the Linux Virtual Delivery Agent on this template VM. Create a machine catalog in Citrix Studio using the template VM and then create a delivery group to provision the Linux VMs to enterprise users.

Reference: Citrix docs: Linux Virtual Delivery Agent

Citrix Cloud and Machine Provisioning

Citrix Cloud manages the operation of the control plane for Citrix DaaS environments. Delivery controllers, management consoles, SQL database, License Server, StoreFront, and Citrix Gateway are all delivered on Citrix Cloud and managed by Citrix.

The workloads hosting the apps and desktops for users remain under the customer control in the data center of their choice, either cloud or on-premises. These components are connected to the cloud service using an agent called the Citrix Cloud Connector.

Citrix Machine Creation Service uses APIs from underlying hypervisors. These resources can come from the customer’s data center or cloud. Citrix Cloud Connector acts as a bridge between the Citrix Cloud plane and underlying resources. The control plane has access to metadata, such as login details, machine names and application shortcuts, restricting access to the customer’s intellectual property from the control plane.

Data flowing between the cloud and customer premises uses secure TLS connections over port 443.

While provisioning VMs using the MCS method ensure that the hypervisor or cloud service has enough processors, memory and storage to accommodate virtual machines.

Installing the latest hypervisor tools on the golden image is required so that applications and desktops function normally. It is advised to not run Sysprep on master images as MCS handles machine identity itself.

Reference: Citrix docs: Citrix Cloud and Machine provisioning

Common use case

Citrix MCS is a best fit for production environments which meet the criteria as follows:

  • Deploying in a cloud environment
  • Intending to deploy NFS storage or clustered shared volumes
  • Availability of high IOPS storage (MCS directs more read activity to the shared storage)

Citrix MCS offers a simple management plane through Citrix Studio and easy to provision workloads from a single UI. There is no extra infrastructure needed. Let’s assume running mixed workloads using the Citrix MCS provisioning method. This includes hosted shared desktops, Linux VMs, full clone VMs, GPU-based workloads and a few Windows apps.

The above diagram is a conceptual deployment scenario for running mixed workloads that support task workers and power users in the same environment. The task worker workload is deployed through hosted shared desktops while the power users are using dedicated VMs deployed and separated into different datastores, as these VMs are the highest in IOP usage.

In the above deployment scenario, there is more than one delivery controller deployed in the environment to achieve high availability and load balancing. Delivery controllers are equipped with adequate processing power and memory to handle the user traffic. Microsoft SQL Servers are deployed in a high availability model so that if any one database server goes down, delivery controller operations like fetching the user details, responding to StoreFront requests are not impacted.

As the number of applications increases, resource consumption also goes up in the environment. It is best practice to pre-calculate the number of users and types of workloads that are going to run in the environment. Citrix MCS is simple to manage from Citrix Studio, there is no extra infrastructure required hence it is easy to deploy on leading hypervisors and cloud platforms.

Best practices for MCS with Citrix Virtual Apps and Desktops

There are several aspects that must be taken into account before provisioning virtual machines using Citrix Machine Creation Services. Citrix MCS is capable of delivering virtual RDS and VDI workloads on Citrix Hypervisor, Hyper-V, vSphere, AHV and also with leading cloud providers.

The following infrastructure considerations should be addressed before provisioning virtual machines using Citrix MCS

  • Storage
  • Temporary Cache
  • OS optimization
  • Delivery controller
  • Scalability

Storage

Storage configuration and sizing’s are the deciding factor when using Citrix Machine Creation Services.

Capacity Considerations: When VMs are created using Citrix MCS a minimum of two disks are created: one is the delta disk containing the OS as copied from the master image and the other one is the identity disk (16 MB) containing Active Directory identity data for each VM. Extra disks can be added to satisfy certain use cases.

The Citrix Hypervisor IntelliCache feature, creates a read-only disk of the master VM on local storage on each host. It is recommended to pre-calculate storage before provisioning the end user machines.

Hypervisor overhead: Different hypervisors create specific sets of files that generate overhead on a per VM basis. For example, log files, hypervisor specific configuration files and snapshot files are also saved on the storage.

Process overhead: Initial catalog creation requires the base disk to be copied to each storage repository. Adding a new machine to a catalog does not require copying the base disk to each storage repository. The catalog updates process creates an extra base disk on each storage repository and can also experience temporary storage peak.

Others: RAM sizing and thin/thick provisioning approaches are also considered for provisioning the virtual machines.

Temporary Cache / MCS storage I/O optimization

Temporary cache in a catalog includes two options, the first one with memory and the second one on disk. With memory or disk, part of the resource is consumed for temporary cache operations, hence it is recommended to check available memory and disk space from the host where VMs are running. In the the case using disk for temporary cache for better performance, SSD disks or high IOPS storage solutions are recommended.

OS optimization

For better performance and to minimize the consumption of resources on the host, it is recommended to optimize the operating system by running the Citrix Optimizer Tool.

Citrix Optimizer: By default, Microsoft Windows desktop images contain numerous features that aren’t needed in a VDI environment. The Citrix Optimizer is a Windows tool developed by Citrix to help administrators optimize various components in their environment. The tool is PowerShell based, but also includes a graphical UI.

Citrix Optimizer provides various templates for optimization. Choose the right template for the operating system so that unnecessary services, configuration entries, and applications are disabled or removed. Admins can expect to realize fairly significant performance gains after optimization.

To download and install the latest Citrix Optimizer visit: https://support.citrix.com/article/CTX224676.

Delivery Controller

In Citrix MCS deployments, the Delivery Controller is the core component of the infrastructure. It is recommended to deploy delivery controllers and Microsoft SQL Server in high availability mode so that if any one delivery controller goes down normal operations will not be impacted.

In medium or large-scale deployments, delivery controllers must have enough memory and computing power so that there will not be any CPU and memory bottlenecks in the environment.

While connecting to hosting resources, make sure to check the compatible version of the hypervisor so that there will be no issues while provisioning. It is recommended to keep the master copy in the high IOPS data store /LUN on SSD or NVMe drives so that maximum efficiency and performance can be achieved.

Scalability

The Machine Creation Services functionally is bundled within the delivery controller and this interacts with the underlying hypervisor and cloud provider framework APIs. When expansion of the environment storage, it can become a bottleneck so it is recommended to have extra storage clusters available so that scalability will not be impacted.

In medium and large-scale deployment, resource consumption is more as end user demand grows, it is recommended to deploy optimized images so that unwanted applications will not consume excessive resources.

When deploying and managing Citrix MCS (Machine Creation Services), various services and communication channels are involved. Knowing the specific port numbers and services names used by Citrix MCS is important for ensuring proper communication between components in your Citrix environment.

Common Ports and Services for Citrix MCS

  1. Port 80 (HTTP) / Port 443 (HTTPS)
    1. Service: Citrix Delivery Controller communication.
    1. Description:
      1. Citrix MCS communicates with the Citrix Delivery Controller to manage machine creation, image updates, and VM provisioning. This traffic occurs over HTTP (port 80) or HTTPS (port 443).
    1. Used for:
      1. Communication between the Delivery Controller and Virtual Desktops (VDAs), including Power Management commands (start/stop/reboot VMs).
  2. Port 8080
    1. Service: Citrix Machine Identity Service (MCS)
    1. Description:
      1. Citrix Machine Identity Service operates on port 8080, facilitating communication between the Citrix Delivery Controller and hypervisors (e.g., Citrix Hypervisor, VMware vSphere) to provision and manage VMs created using MCS.
    1. Used for:
      1. Creating and managing MCS-based virtual machines from a master image.
  3. Port 16500-16509 (Provisioning Ports)
    1. Service: Citrix Machine Creation Services
    1. Description:
      1. These ports are reserved for provisioning VMs in Citrix MCS environments. They enable communication between the Citrix Delivery Controller, the Citrix Studio, and hypervisors (e.g., XenServer, VMware, or Hyper-V).
    1. Used for:
      1. Transmitting provisioning commands between the controller and hypervisors during the creation and management of virtual desktops.
  4. Port 1494
    1. Service: ICA (Independent Computing Architecture)
    1. Description:
      1. Port 1494 is used by the Citrix ICA protocol, which is essential for end-users to connect to virtual desktops and applications via Citrix Workspace App.
    1. Used for:
      1. End-user connections to their MCS-provisioned virtual desktops and applications.
  5. Port 2598
    1. Service: Session Reliability (TCP)
    1. Description:
      1. This port is used by Citrix for session reliability. It works with ICA (Independent Computing Architecture) to ensure that user sessions stay active even during network interruptions.
    1. Used for:
      1. Ensuring reliability of user connections to MCS-based virtual desktops in cases of temporary network disruptions.
  6. Port 7279
    1. Service: Citrix Licensing
    1. Description:
      1. This port is used by Citrix Licensing service for communication between Citrix products and the Citrix Licensing Server.
    1. Used for:
      1. Managing and validating licenses for Citrix Virtual Apps and Desktops environments.
  7. Port 8443
    1. Service: Machine Creation Services Secure Communication
    1. Description:
      1. For secure communications with hypervisors, MCS might use port 8443. This is typical for operations related to virtual desktop provisioning over SSL (HTTPS).
    1. Used for:
      1. Secure provisioning and management commands between Citrix Delivery Controller and hypervisors (VMware, Hyper-V).

Summary of Key Ports for Citrix MCS:

Port NumberService NameDescription
80 / 443Citrix Delivery ControllerMCS-to-Controller communication for VM provisioning and power management (HTTP/HTTPS).
8080Citrix Machine Identity Service (MCS)Communication between Delivery Controller and hypervisors for machine provisioning.
16500-16509MCS Provisioning PortsReserved for VM provisioning between Controller, Studio, and hypervisors.
1494ICA (Independent Computing Architecture)Used for ICA protocol to provide virtual desktop access to users.
2598Session Reliability (TCP)Keeps ICA sessions alive during network interruptions.
7279Citrix LicensingManages communication between Citrix products and the Citrix Licensing Server.
8443MCS Secure CommunicationSecure (SSL) provisioning and management commands between the controller and hypervisors.

Services Involved in Citrix MCS:

  1. Citrix Machine Creation Service:
    1. The primary service responsible for creating and managing virtual desktops and servers in Citrix Virtual Apps and Desktops environments.
  2. Citrix Delivery Controller:
    1. Coordinates and manages the lifecycle of virtual desktops, including the interaction with Citrix MCS for provisioning VMs from a master image.
  3. Citrix Studio:
    1. The management console where administrators configure and manage MCS, including the creation of catalogs and virtual machines.
  4. Hypervisor Management Service:
    1. This service handles communication between Citrix MCS and the underlying hypervisor (such as Citrix Hypervisor, VMware, or Hyper-V).
  5. Citrix Licensing Service:
    1. Responsible for managing and verifying the licenses for the MCS-provisioned virtual desktops and applications.

In Citrix Machine Creation Services (MCS), a catalog represents a collection of virtual machines (VMs) that are created from a master image and managed collectively. When setting up MCS, you can choose between different catalog types depending on the needs of your environment, particularly in terms of persistence (whether or not user data and machine states are preserved across sessions).

Citrix MCS Catalog Types

  1. Non-Persistent (Random) Catalogs:
    1. Description: These VMs are stateless and do not retain any changes after a user logs off. Each time a user logs in, they are assigned a VM from a pool, and that VM reverts to a clean state from the master image after each session.
    1. Key Characteristics:
      1. User data and machine states are not saved after logoff.
      1. Ideal for stateless environments where users don’t need to retain data between sessions.
      1. VMs are destroyed and re-provisioned or refreshed upon logoff.
      1. Common in kiosk, call center, or lab environments where users need access to clean, unmodified desktops for each session.
    1. Use Case:
      1. Shared desktops, temporary sessions, or environments where personal settings or files do not need to persist.
    1. Example: A student lab where each user logs into a random VM for a clean environment.
  2. Persistent (Dedicated) Catalogs:
    1. Description: These VMs are stateful and maintain user changes across sessions. Each user is assigned a dedicated VM that retains any changes made to the system or user profile after logoff.
    1. Key Characteristics:
      1. User changes are saved across sessions, meaning data, applications, and settings persist.
      1. Each user is assigned a dedicated VM, and they always log into the same machine.
      1. Suitable for environments where users need to maintain settings, applications, or documents across logins.
      1. Persistent disks or separate personal vDisks are used to store user data.
    1. Use Case:
      1. Environments where users require a customized desktop experience and need their apps, files, and settings to persist.
    1. Example: A developer or IT admin with specific tools and settings who logs into the same virtual machine every time.
  3. Multi-session OS Catalogs:
    1. Description: Instead of creating individual VMs for each user, this catalog type provisions Windows Server OS as a multi-session operating system, allowing multiple users to log into the same server instance simultaneously.
    1. Key Characteristics:
      1. Based on Windows Server OS, which supports multiple users logged in simultaneously.
      1. Cost-effective, as multiple users share the same server resources.
      1. Users still receive an individual desktop session, but multiple users share the underlying resources.
      1. User data and profiles are managed using profile management tools (e.g., Citrix Profile Management, FSLogix).
    1. Use Case:
      1. Scenarios where multiple users need access to the same set of applications, but individual desktops aren’t required.
    1. Example: Shared environments like a remote desktop session host (RDSH), where users access a shared server instance.
  4. Azure/Cloud-Based MCS Catalogs:
    1. Description: When deploying VMs in a public cloud environment such as Microsoft Azure or AWS, Citrix MCS provides catalog types tailored to the cloud infrastructure. These catalogs support both persistent and non-persistent VMs.
    1. Key Characteristics:
      1. Cloud-native features such as autoscaling and cost-optimization options.
      1. VMs can be deployed using Azure or AWS as the hypervisor, allowing for integration with cloud services and dynamic scaling based on demand.
      1. Supports persistent and non-persistent catalogs, as well as multi-session OS options.
    1. Use Case:
      1. Cloud-based virtual desktop infrastructure (VDI) where workloads are dynamically scaled.
    1. Example: A business using Azure Virtual Desktop (AVD) to scale virtual desktops for remote employees.

Comparison of MCS Catalog Types

Catalog TypePersistenceUser AssignmentBest ForExample Use Case
Non-Persistent (Random)NoRandom VM per sessionStateless environmentsCall centers, labs, kiosks
Persistent (Dedicated)YesDedicated VM for each userPersonalized desktops, user settings persistDevelopers, knowledge workers
Multi-session OSYes (Session-based)Shared server (multiple users)Multi-user environmentsRDSH, cost-effective shared desktops
Azure/Cloud-Based MCSYes/NoDepends on cloud setupCloud VDI, dynamic scalingAzure Virtual Desktop, AWS WorkSpaces

Key Considerations When Choosing a Citrix MCS Catalog Type:

  • Persistence Needs: Do your users need to retain their settings, files, and installed applications across sessions? If yes, persistent catalogs are ideal.
  • Scalability and Cost: Non-persistent and multi-session catalogs are often more cost-effective and easier to scale for environments with a large number of users who don’t need persistent desktops.
  • User Experience: If you need dedicated desktops where users require personalized environments, choose persistent catalogs.
  • Cloud vs. On-Premises: If your infrastructure is in the cloud (e.g., Azure, AWS), the cloud-based MCS catalogs are tailored to the specific features of cloud environments, such as autoscaling.

Leave A Reply

Your email address will not be published. Required fields are marked *

You May Also Like

We are excited to announce another remarkable achievement at Cloudsoft Solutions! In the past six days, we successfully secured placements...
Citrix DaaS Questions: Citrix DaaS Deployment & Management: Citrix DaaS Administration & Monitoring: Citrix DaaS Security: Citrix DaaS Troubleshooting: Advanced...
1. AWS CloudFormation AWS CloudFormation is a service that enables you to model and set up your Amazon Web Services...
×

Hello!

Click one of our contacts below to chat on WhatsApp

×