CCI Talking Points:

• Module 4: Provision and Deliver App and Desktops Resources | Total Time: 97 minutes
• 62 Slides | Lecture Time: 60 minutes
• 5 Labs | Lab Time: 37 minutes
• 4-1: Create a Machine Catalog for Multi-session OS (Server OS) using MCS
• 4-2: Create a Delivery Group for Server OS

© 2020 Citrix | Confidential

 • 4-3: Create Machine Catalog for Single-session OS (Desktop OS) using MCS
• 4-4: Create Delivery Group for Desktop OS
• 4-5: Update a Machine Catalog for Single-session OS (Desktop OS)
• The purpose of this module is to:
• Give students an understanding of how to provision and deliver desktop and application resources to end
users.

1 © 2020 Citrix | Confidential

CCI Talking Points:
• [Point 1]
• We explain the purpose of machine catalogs, Remote PC and Delivery Groups.
• [Point 2]
• We will identify the methods to provision resources.
• [Point 3]

© 2020 Citrix | Confidential

 • We will deep dive the process of MCS.
• [Point 4]
• We will discuss the considerations regarding static desktops with regards to rebooting and updating.
• [Point 5]
• We will Present the Resource Location considerations for machine catalogs.

Delivery Preparation:
• A sign of a great instructor is his or her ability to provide meaningful overviews of the course content as it
relates to both the learning trajectory of the course, and also to student experiences.
• In addition, this is the first chance that students will understand (short of reading the online catalog) what is
and is not specifically covered in the course and module.

2 © 2020 Citrix | Confidential

© 2020 Citrix | Confidential
Key Notes:
• Machine Catalogs are separated by:
• Machine Type and OS:
• Windows Server OS
• Windows Desktop OS

© 2020 Citrix | Confidential

 • Linux Workstation OS
• Linux Server OS
• Remote PC
• Provisioning Method:
• Machine Creation Services (MCS)
• Citrix Provisioning (PVS)
• Existing
• The machine type maps to the different FlexCast models described in Module 1 (e.g. Windows Server OS
could be for published desktops and/or Server OS published apps).
• All VMs in a catalog will have the same VDA version and the same apps/desktops. Typically, there is a master
image that is used to create all VMs in a machine catalog.
• The existing machines option is for machines that have already been prepared using a non-Citrix technology.
• Since machine catalogs can span hypervisor hosts, it is important to make sure that where applicable, master
images are accessible from all hosts.
• During machine catalog creation, the following should also be specified:
• (1) Power management of machines (“power managed” only permitted if a hypervisor or cloud connection
has already been configured)
• (2) Desktop experience if Desktop OS is selected as the machine type (connect to same or random
desktop). If users will connect to the same desktop, select if changes will persist.
• 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 Citrix Provisioning, computer accounts for target devices are managed differently;
see the Citrix Provisioning documentation.

Additional Resources:
• Create machine catalogs: 1912 LTSR: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-
ltsr/install-configure/machine-catalogs-create.html

4 © 2020 Citrix | Confidential

Key Notes:
• Resource locations contain the resources required to deliver applications and desktops to users.
• Cloud Connectors must reside in a resource location.
• A default resource location will be created with the first Cloud Connector installation.
• Can be renamed.
• In the Citrix Virtual Apps and Desktops environment, resource locations contain the resources required to deliver

© 2020 Citrix | Confidential

 applications and desktops to users. You manage those items from Citrix Cloud and the Citrix Virtual Apps and
Desktops management console. Typically, resources include:
• Active Directory domain controller
• Hypervisors or cloud services, known as hosts
• Virtual Delivery Agents (VDAs)
• Citrix ADC (optional): To enable secure external access to the applications and desktops offered to users,
add a Citrix ADC VPX appliance to the resource location and set up Citrix Gateway.
• For a proof-of-concept deployment that requires only internal access, you can use the cloud-hosted
StoreFront that comes with Citrix Cloud.
• Citrix StoreFront servers (optional)
• To communicate with Citrix Cloud, every resource location must contain a Citrix Cloud Connector. At least two
Cloud Connectors per resource location is recommended, for availability.
• A resource location is considered a zone in a Citrix Virtual Apps and Desktops environment.

Additional Resources:
• Set up resource locations - https://docs.citrix.com/en-us/xenapp-and-xendesktop/service/install-
configure/resource-location.html

5 © 2020 Citrix | Confidential

Key Notes:
• Customers start a configuration of Citrix Virtual Apps and Desktops Service by creating a Host connection, followed by
creating a Machine Catalog and then a Delivery Group.
• The steps to create a Host Connection, Machine Catalog and Delivery Group are exactly the same as those for an on-
premises Citrix Virtual Apps and Desktops site.
• Add Hosting Connections:

© 2020 Citrix | Confidential

 1. Click Manage. The management console opens. If a connection has not been created yet, you are guided
to that step.
2. Select Configuration > Hosting in the navigation pane.
3. Select Add Connections and Resources in the Actions pane.
4. Create a new Connection. Select your hypervisor and type in the credentials.
5. Select the desired Storage for the hosting connection.
6. If deploying on Azure ARM, select the desired Region.
7. Select the desired Network where VDAs will be deployed.
• Citrix Virtual Apps and Desktops equally supports all of the following:
• Citrix Hypervisor (formerly known as Citrix XenServer)
• Microsoft System Center Virtual Machine Manager.
• VMware vSphere
• CloudPlatform
• Microsoft Azure Resource Manager
• Nutanix Acropolis
• Amazon EC2
• Oracle Cloud Infrastructure (OCI) Classic, for Citrix Virtual Apps and Desktops Service Only
• Hypervisor requirements:
• If using a VMware vCenter self-signed certificate, the certificate needs to be added to the Citrix Cloud
Connector.
• If using a Hyper-V and System Center Virtual Machine Manager (SCVMM), the SCVMM Console must be
installed on the Citrix Cloud Connector.
• If using Citrix Hypervisor, consider deploying a certificate on the hosts and trusting it on the Cloud
Connectors.

Additional Resources:
• Create and manage connections - https://docs.citrix.com/en-us/xenapp-and-xendesktop/service/install-
configure/connections.html
• Citrix Virtual Apps and Desktop 7 Build 1808 System Requirements, under Host / virtualization resources:

6 © 2020 Citrix | Confidential

 • On-Premises or Public Cloud: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/system-
requirements.html
• Citrix Cloud Service: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops-service/system-
requirements.html

6 © 2020 Citrix | Confidential

CCI Talking Points:
• Do not go into depth on MCS, as this is just an introduction slide.
• Do not go into depth on PVS; instead this is a upsell opportunity to the CXD-304 or CXD-310 course.

Key Notes:
• Machine Creation Services is a very simple way of enabling single image management.

© 2020 Citrix | Confidential

 • MCS will allow you to create a number of unique machines from one single master machine by utilizing
storage level cloning and a number of mechanisms, that will individualize these machines after cloning.
• Citrix Provisioning is a little more complex to install and configure.
• It will, like MCS, allow you to deploy a number of VDAs all from a single image.
• PVS is typically for larger and more complex environments.
• Remember our deployment in this course for WW Labs addresses a more simple Proof of Concept.
• The focus of our deployment is MCS.
• Citrix Provisioning is an optional component of Citrix Virtual Apps and Desktops available with some editions.
It provides an alternative to MCS for provisioning virtual machines. Whereas MCS creates copies of a master
image, Citrix Provisioning streams the master image to user device. Citrix Provisioning doesn’t require a
hypervisor to do this, so you can use it to host physical machines. When Citrix Provisioning is included in a
Site, it communicates with the Controller to provide users with resources.

Additional Resources:
• Create machine catalogs:
• 1912 LTSR: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/install-configure/machine-
catalogs-create.html

Delivery Preparation:
• This is not the time to explain what Citrix Provisioning (PVS) is or how to use it beyond the slide.
• Instead this is a valuable upsell opportunity for the students to attend the CXD-304 or CXD-310.

7 © 2020 Citrix | Confidential

Key Notes:
• Remote PC Access allows an end user to log on remotely from virtually anywhere to the physical Windows PC in the
office. The Virtual Delivery Agent (VDA) is installed on the office PC; it registers with the Delivery Controller and
manages the HDX connection between the PC and the end user client devices. Remote PC Access supports a self-
service model; after you set up the whitelist of machines that users are permitted to access, those users can join their
office PCs to a Site themselves, without administrator intervention. The Citrix Workspace app running on their client

© 2020 Citrix | Confidential

 device enables access to the applications and data on the office PC from the Remote PC Access desktop
session.
• Remote PC Access is a feature of Citrix Virtual Desktops and can be used as an interim stage during
migration of physical office PCs to virtual machines.
• Remote PC Access can be a solution for employees to access their documents and applications during
roadblocks, quarantine or bad weather.
• Remote PC access is secure by design
• Remote PC enables mobile device access to office PC’s as well.
• The following Citrix Virtual Desktops features are not supported for Remote PC Access deployments:
• Creating master images and virtual machines
• Delivering published apps
• Personal vDisks
• Client folder redirection

Additional Resources:
• Create machine catalogs:
• 1912 LTSR: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/install-configure/machine-
catalogs-create.html
• Remote PC Access:
• 1912 LTSR: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/install-configure/remote-pc-
access.html
• Remote Access Design Guide: https://www.citrix.com/content/dam/citrix/en_us/documents/products-
solutions/remote-access-to-enterprise-pc-xendesktop-75-desktop-guide.pdf (this content is based on 7.5
but the design guidelines are still relevant)

8 © 2020 Citrix | Confidential

CCI Talking Points:
• Dissect the the first bullet to explain the functional process:
• “A collection of virtual or physical machines, selected from one or more machine catalogs…”

Key Notes:

© 2020 Citrix | Confidential

 • A Delivery Group is the Site assigning specific apps and or desktops to the designated users.
• Collection of machines that specify which user groups can access desktops or applications.
• Allocates machines from the machine catalog(s) for user access.
• Specifies the delivery type:
• Desktops
• Applications
• Desktops and applications
• Assigns user groups or unauthenticated users to resources.
• A Delivery Group is a collection of machines selected from one or more machine catalogs. The Delivery Group
specifies which users can use those machines, and the applications available to those users.
• A machine can only be in one Delivery Group.
• The “desktops and applications” option for delivery type is not available with static Desktop OS desktops.
• Leading practice: assign Active Directory groups (rather than individual AD accounts) to Delivery Groups
because it can be easier to add a user to the appropriate AD groups to gain access to the necessary
resources when onboarding a user to the environment. This can also reduce the operational complexity
involved with removing user access.
• For Delivery Groups containing Server OS machines, you can select a check box that will allow users to
access applications and desktops without presenting credentials to StoreFront or Citrix Workspace app. For
example, when users access applications through kiosks, the application might require credentials, but the
Citrix access portal and tools do not. An Anonymous Users Group is created when you install the VDA.

Additional Resources:
• Create Delivery Groups:
• 1912 LTSR: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/install-configure/delivery-
groups-create.html

9 © 2020 Citrix | Confidential

CCI Talking Points:
• Mention that applications can also be published across multiple Delivery Groups using Application Groups. Application
Groups will be covered in module 7.

Key Notes:
• A list displays the applications that were discovered on a machine created from the master image, a template in the

© 2020 Citrix | Confidential

 machine catalog, or on the App-V management server. Choose one or more applications to add to the
Delivery group.
• You can also add (create) applications manually. You’ll need to provide the path to the executable, working
directory, optional command line arguments, and display names for administrators and users.
• There are more options for publishing applications that can be accessed by clicking Application properties,
including command line parameters, application names, and limiting the visibility of apps. Also, can change the
application folder that the application is displayed in by clicking Change under the Place the selected
application in folder title. More detail regarding this will be discussed in later module.
• Application Groups let you manage collections of applications. You can create Application Groups for
applications shared across different Delivery Groups or used by a subset of users within Delivery Groups.
Application Groups are optional; they offer an alternative to adding the same applications to multiple Delivery
Groups. Delivery Groups can be associated with more than one Application Group, and an Application Group
can be associated with more than one Delivery Group.
• Application Groups will be covered in module 7.

Additional Resources:
• Create Delivery Groups: 1912 LTSR: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/install-
configure/delivery-groups-create.html

10 © 2020 Citrix | Confidential

CCI Talking Points:
• In this release Citrix Virtual Apps and Desktops 7 1912 Long Term Service Release (LTSR). Server and Desktop OS
Machine Catalogs have been renamed as: Multi-session OS and Single-session OS:
• Multi-session OS: The Server OS Machine Catalog that provides hosted shared desktops for a large-scale
deployment of standardized Windows Server OS or Linux OS machines.
• Single-session OS: The Desktop OS Machine Catalog that provides VDI desktops ideal for a variety of different

© 2020 Citrix | Confidential

 users.
• Explain the different scenarios for a Delivery Group having machines from multiple Machine Catalogs.
• Explain that there are also scenarios where a Machine Catalog will contribute machines to multiple Delivery
Groups.
• Mention that applications can also be published across multiple Delivery Groups using Application Groups.
Application Groups will be covered in module 7.

Key Notes:
• During the creation of a Delivery Group, select a Machine Catalog and specify the number of machines you
want to use from the catalog.
• To use a specific Machine Catalog, at least one machine must remain unused in that catalog.
• A Machine Catalog can be specified in more than one Delivery Group; however, a machine can be used in
only one Delivery Group.
• A Delivery Group can use more than one Machine Catalog; however, those catalogs must contain the same
machine types (Multi-session OS, Single-session OS, or Remote PC Access). In other words, you cannot
mix machine types in a Delivery group or in a Machine Catalog.
• Similarly, you cannot create a Delivery Group containing Desktop OS machines from a Machine Catalog
configured for static desktops and machines from a Machine Catalog configured for random desktops.
• Each machine in a Remote PC Access machine catalog is automatically associated with a Delivery Group.
• Application Groups are optional; they offer an alternative to adding the same applications to multiple Delivery
Groups. Delivery Groups can be associated with more than one Application Group, and an Application Group
can be associated with more than one Delivery Group. Application Groups will be covered in detail in Module
7.

Additional Resources:
• Create Delivery Groups: 1912 LTSR: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/install-
configure/delivery-groups-create.html

11 © 2020 Citrix | Confidential

© 2020 Citrix | Confidential
© 2020 Citrix | Confidential
Key Notes:
• This course explains a high level of both methods and then provide a deep dive into Machine Creation Services; those
interested in a deep dive of Citrix Provisioning will attend the CXD-304 course.
• Ask your Citrix Instructor about the difference between the CXD-304 course and the CXD-310 course.
• MCS or PVS does not work for Remote PC.
• MCS utilizes the underlying hypervisor APIs (Citrix Hypervisor Hyper-V, or vSphere) to create, start, stop, and delete

© 2020 Citrix | Confidential

 catalog virtual machines.
• Please note, MCS is not available for physical machines.
• Manual Provisioning:
• Although supported, Manual Provisioning is not recommended, because there is no guaranteed
consistency between machines in a catalog, because each could have been built individually, by different
administrators.
• Manual provisioning is not the Citrix preferred method.
• Some customers are forced to provision the machines running the VDAs manually. For example:
• The Citrix Admin Team does not have appropriate permissions to use MCS on the hypervisor or storage.
• Some applications may need special installation procedures and cannot be installed and cloned via MCS
or PVS
• Some Citrix customers are using manual creation methods. Although fully supported, manual provisioning
has some potential drawbacks:
• There is no central management for deployment or updates.
• Does not address and minimize the storage footprint of a machine catalog.
• Does not address any storage I/O optimization.
• Takes far longer to create larger machine catalogs.
• Creates risk for potential inconsistencies for the machines within the machine catalog.
• Consider MCS Full Clone can substitute the need for manual provisioning in many cases.

Additional Resources:
• XenApp and XenDesktop 7.11 MCS Full Clone Support (Link still holds true for Build 1808):
https://www.citrix.com/blogs/2016/10/12/xenapp-and-xendesktop-7-11-mcs-full-clone-support/

14 © 2020 Citrix | Confidential

CCI Talking Notes:
• Do not go into any depth on this slide.
• This is a preview only.
• PVS is covered in the other courses.
• MCS is covered deep dive in the next lesson.

© 2020 Citrix | Confidential

 Key Notes:
• Both MCS and Citrix Provisioning are supported with Citrix Cloud
• This course only covers MCS in depth.

Delivery Preparation:
• Do not go into very much detail in this particular slide, this is simply to provide students with a framework to
organize what will be discussed.
• Set expectations that PVS will be covered at a very high level, and that for more information, students can
take additional training.

15 © 2020 Citrix | Confidential

Key Notes:
• In previous versions it was easier to choose between MCS and PVS, but the feature gap is much smaller today.
• MCS:
• MCS does not require administrators to build out additional infrastructure or to learn another product, decreasing time
and build requirements.
• MCS provides administrators with a quick way to deploy multiple VMs from single shared image, decreasing time to

© 2020 Citrix | Confidential

 production rollout.
• MCS has added RAM based caching to put performance on par with PVS.
• MCS can now utilize full clones to accommodate backup and storage replication of virtual machines.
• A copy of the master image needs to be stored in each storage repository configured for the host
connection for MCS, increasing storage requirements.
• MCS does not include a versioning feature that enables the same steady promotion from maintenance ->
test -> production as PVS does.
• MCS cannot be used with physical machines.
• PVS:
• PVS has a unique versioning feature that allows for fast and easy update and roll back of updates.
• PVS can work with physical machines as well as virtual machines.
• PVS can host the images on local storage, reducing the need to plan for SAN capacity.
• PVS maintains the image in a .vhd or .vhdx file (also known as the vDisk), so if we have multiple
datacenters, we can simply copy the vDisk image between them using any preferred file sharing
mechanism.
• PVS relies on the networking infrastructure in place, as it streams the image over the network.
• PVS requires additional infrastructure to be installed and configured for high availability and redundancy.
Also, administrators will need to learn how to build, configure, and manage the technology.
• PVS does not have built in cloud deployment features. To use PVS on AWS or Azure, a separate PVS
environment has to be created in the cloud.

Additional Resources:
• Provisioning Services or Machine Creation Services (2016 Edition):
https://www.citrix.com/blogs/2016/06/28/provisioning-services-or-machine-creation-services-2016-edition/

16 © 2020 Citrix | Confidential

© 2020 Citrix | Confidential
© 2020 Citrix | Confidential
CCI Talking Points:
• Read carefully the sub-title text: Explain that:
• The next 14 slides cover the MCS deep-dive process.
• Although it’s tuned for On-Premises, the only difference with a Citrix Cloud Site process is MCS is the Cloud
Connector communicating with the Hypervisors and Active Directory (AD).

© 2020 Citrix | Confidential

 Key Notes:
• MCS leverages a linked-clone approach to provisioning, with virtual machines reading from a read-only master
image that has been de-personalized.
• 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.
• MCS also supports full clone copies, where the entire image is copied to each VM and does not use a
differencing disk.
• MCS can now be used in on-premises, Azure, and AWS resource locations, with or without Citrix Cloud. It can
be used to provision Windows and Linux VDA machines.

Additional Resources:
• MCS Storage Considerations: https://support.citrix.com/article/CTX218082

19 © 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

Key Notes:
• In this step, the administrator is creating a virtual machine that has the necessary configurations and applications

© 2020 Citrix | Confidential

 required for the targeted use case.
• Note that deleting, moving, or renaming master images will prevent administrators from being able to revert a
machine catalog if necessary.

20 © 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

Key Notes:
• There are two options:

© 2020 Citrix | Confidential

 • Manual: the administrator takes a snapshot of the master VM. This option is considered leading practice
because it enables the administrator to determine a desired, meaningful naming convention.
• Automatic: if a snapshot is not taken, when the administrator selects the master VM in the MCS wizard,
Studio will automatically take a thin snapshot of the VM using an automatic naming scheme and will
provide that snapshot to MCS.

21 © 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

Key Notes:
• MCS is creating a full copy of the snapshot that was provided so that all machines that will be provisioned will have the

© 2020 Citrix | Confidential

 same desired properties and configurations from the master VM.
• MCS creates a full copy of the snapshot and stores it so that it can be updated in order to provision multiple
VMs, and so that there is no impact if the administrator deletes the original snapshot.

22 © 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

Key Notes:
• A temporary virtual machine is created from the snapshot so that an image preparation process can be run to

© 2020 Citrix | Confidential

 depersonalize the VM.
• The Preparation VM is created with the network disconnected to prevent any issues with the operation of the
original master image.

23 © 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

Key Notes:
• The Instruction Disk will tell the Preparation VM the steps that need to be run in order to depersonalize the VM.

© 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

© 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

Key Notes:
• The PvD inventory step is only applicable if the Personal vDisk feature is being used, which will be discussed later in

© 2020 Citrix | Confidential

 the module.
• The image preparation process is where the Preparation VM runs through the list of instructions that it
obtained from the Instruction Disk. It is depersonalizing the copy of the snapshot to change the base OS so
that it can be used to provision multiple machines. This is why sysprep does not need to be run manually
when creating a master image with MCS, because the image preparation process automatically performs
the necessary de-personalization.

Additional Resources:
• Machine Creation Service: Image Preparation Overview and Fault-Finding:
https://www.citrix.com/blogs/2016/04/04/machine-creation-service-image-preparation-overview-and-fault-
finding/

26 © 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

Key Notes:
• The preparation VM updates the copy of the snapshot following the image update process, represented in the diagram

© 2020 Citrix | Confidential

 by the copy of the snapshot being updated from A’ to A’’.

27 © 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

© 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

Key Notes:
• The instruction disk reports the success/failure of the steps run during the image preparation process and only moves

© 2020 Citrix | Confidential

 on with the MCS process if the steps were successfully completed. After reading the report back to MCS, the
instruction disk is then deleted.

Additional Resources:
• Machine Creation Service: Image Preparation Overview and Fault-Finding:
https://www.citrix.com/blogs/2016/04/04/machine-creation-service-image-preparation-overview-and-fault-
finding/

29 © 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

© 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

Key Notes:
• Now that the copy of the snapshot has been updated and prepared for use with multiple VMs, the copy can be

© 2020 Citrix | Confidential

 replicated to each storage repository configured for the host connection.
• The copy of the snapshot is read-only, and the virtual machines will reference the copy of the snapshot in the
applicable storage repository.
• Important to note that because the snapshot copy needs to be placed in each storage repository, the number
of storage repositories will affect storage requirements.

31 © 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

Key Notes:
• The identity disks for each VM are created in memory.

© 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

Key Notes:
• MCS creates each VM by attaching the identity disk and creating and attaching a differencing disk. This is done for each

© 2020 Citrix | Confidential

 VM that needs to be created.
• Since each virtual machine is pointing to the read-only snapshot copy, the virtual machines need a unique
identity (provided by the identity disk) and a disk to handle its writes (provided by the differencing disk).

33 © 2020 Citrix | Confidential

CCI Talking Points:
• Don’t present the Key Notes, slides 20-34 are designed to be presented as a step by step; use only the content on the
slide and then move on to the next one.

Key Notes:
• With the release of version 7.9 through 7.12 we have three new features that bring the performance of MCS on par with

© 2020 Citrix | Confidential

 Citrix Provisioning.
• We can specify several Storage Repositories per hosting connection, allowing administrators to utilize less
expensive local storage, rather than expensive SAN solutions.
• We can configure a Machine Catalog to use RAM to optimize the temporary writes (similar to the PVS option
“write cache in memory with offload to disk”).
• We can configure the latest release of Citrix Hypervisor to cache the common Shared OS disk in memory to
further minimize central I/O load. (This feature is not supported on any other hypervisor).
• Citrix Citrix Hypervisor IntelliCache can optimize read IO.

Additional Resources:
• Introducing MCS Storage Optimization: https://www.citrix.com/blogs/2016/08/03/introducing-mcs-storage-
optimisation/
• Relating IntelliCache and In-memory Read Caching: https://support.citrix.com/article/CTX201887

34 © 2020 Citrix | Confidential

Key Notes:
• Machine Catalogs are a collection of physical or virtual machines with same type of operating system, configuration,
naming convention and provisioning method. These machines are managed as a single entity.
• A Delivery Group is a collection of machines selected from one or more Machine Catalogs. The Delivery Group
specifies which users can use those machines, plus the applications and/or desktops available to those users.
• Creating a Delivery Group is the next step in configuring your deployment after creating a Machine Catalog.

© 2020 Citrix | Confidential

Key Notes:
• In contrast to an on-premises Citrix Studio, the cloud hosted Citrix Studio prompts for a user account having that has
sufficient privileges to create new machine accounts while running the Create Machine Catalog wizard.
• The applications and desktop assignment in a cloud based Citrix Virtual Apps and Desktops Service can either be done
through Delivery Groups within the Cloud Studio or using the Library offerings within the Citrix Cloud Home page.

© 2020 Citrix | Confidential

Key Notes:
• When administrators create a MCS provisioned catalog using Cloud Studio, the Delivery Controller is instructed to
create machines on the hypervisor and create new computer accounts in AD.
• The cloud based Delivery Controllers cannot directly communicate with AD or the hypervisors in the resource location.
• The instructions are proxied to the Cloud Connector Server within the resource location.
• The AD Provider Service on the Connector creates the machine accounts and the Remote HCL provider creates the

© 2020 Citrix | Confidential

 machines on the hypervisors.
• Once machines are created, they register with the cloud Delivery Controller via the Remote Broker Provider.
• This process will work differently when deploying Machine Catalogs to public clouds. In these cases, Citrix
Cloud will typically communicate directly to the public cloud API.

37 © 2020 Citrix | Confidential

© 2020 Citrix | Confidential
© 2020 Citrix | Confidential
Key Notes:
• The differencing disks are discarded because the user changes do not persist for random/non-persistent desktops.
• Since the differencing disks are queued for deletion, this increases the storage consumption and should be taken into
account when determining the storage requirements.
• Hypervisors supporting clone on boot include:
• VMware hypervisors

© 2020 Citrix | Confidential

 • Citrix XenServer 6.1 and up (including current Citrix Hypervisor release)
• Pre- XenServer 6.1 supported for local and ISCSI storage repositories, but not for NFS storage
repositories
• Pre-XenServer 5.6 not supported

40 © 2020 Citrix | Confidential

© 2020 Citrix | Confidential
Key Notes:
• The differencing disk is not deleted following reboot as user changes are required to persist for the static/persistent
desktop.

© 2020 Citrix | Confidential

© 2020 Citrix | Confidential
CCI Talking Points:
• Walk students through the process of updating a random/non-persistent desktop machine catalog.

Key Notes:
• Random/Non-persistent Desktop:
• When the administrator updates the master VM and goes into the machine catalog and selects Update Catalog

© 2020 Citrix | Confidential

 option, this creates a new full copy of the snapshot, which is then updated via the image preparation
process.
• The VMs are then instructed on reboot to point to the latest updated image. VMs that have not been
rebooted will continue to point to the original image snapshot.
• A2 indicates the new version of the master VM.
• It is leading practice to take snapshots or copies of master image for rollback purposes in the event there is
an issue with the update.
• Static/Persistent Desktop:
• Static/persistent desktops can not be instructed to read from an updated master image on reboot due to the
fact that the persistent differencing disks are tied to the original master image.
• Only newly created Catalogs can be instructed to read from an updated master image.
• Updates for existing machines can be done either manually on an individual basis, or collectively through
the use of a third party software distribution tools.
• If Citrix App Layering is used, User Layers will enable you to deploy image updates using MCS while still
preserving user-installed applications and settings. However, this approach should be tested as it may incur
performance and management overhead.
• For more information on Citrix App Layering and User Layers, see the App Layering eLearning content or
the Citrix advanced level trainings.

44 © 2020 Citrix | Confidential

Key Notes:
• There are three high level concepts involved in making a resource available to end users :
1. The machine needs to be defined (this involves the process of determining user experience, sizing and available
resources such as GPU, CPU and RAM, as well as creating the Master Image ).
• Step 1 starts with research and documentation.
• Each group of users has its own requirements in terms of mobility, security, updates & flexibility, provided

© 2020 Citrix | Confidential

 applications, resource impact, level of personalization, high-availability, and other factors. Grouping users
with common requirements together enables them to share a FlexCast model, an image or even a VDA
and allows for more accurate planning.
• Once the research is done, a master image must be defined
1. The correct number of machines need to be provisioned into a Catalog from a master image (typically
done through Machine Creation Services or Citrix Provisioning)
• During Step 2 the actual resources (and maybe their infrastructure) will be created. The resources can be
grouped into Machine Catalogs at this time.
• Choosing the “best” delivery model refers to the “most appropriate” for any given company or resource
group. Some companies benefit largely by choosing just one single model to address all requirements,
while others prefer to have two different models within the same company for different purposes.
2. The resource needs to be assigned to the right users (done through a Delivery Group).
• During Step 3 the actual Delivery Groups are created, providing access for users and groups to their
desktops and applications.

45 © 2020 Citrix | Confidential

© 2020 Citrix | Confidential
© 2020 Citrix | Confidential
Key Notes:
• Place resource locations where they best meet your business needs. resource locations can be in a public cloud, in a
branch office, private cloud, or a corporate data center.
• The choice of location may be impacted by the following:
• Proximity to subscribers
• Proximity to data

© 2020 Citrix | Confidential

 • Scale requirements
• Security attributes
• There is no restriction on the number of resource locations you can build. The overhead of a resource
location is small.
• To provide identity management for subscribers and resources you need to install a Connector to access an
Active Directory.
• This makes it easy to distribute the resources across as many resource locations as you need without
needing to make compromises.
• As an example you could:
• Build a resource location in your data center for the head office based on subscribers and applications
that need to be close to the data.
• Add a separate resource location for your global users in a public cloud. Or build separate resource
locations in branch offices to provide the applications best served close to the branch workers.
• Each resource location should have a minimum of two Cloud Connectors.
• Add a further resource location on a separate network that provides restricted applications. This provides
restricted visibility to other resources and subscribers without the need to adjust the other resource
locations.
• Primary Resource Locations:
• To decide which resource location you want to use for your primary resource location, consider the
following:
• Does the resource location have the best connectivity to your domain?
• Is the resource location the closest to the geographical region in which you use the Citrix Cloud
management console? For example, if your Citrix Cloud console is at https://us.cloud.com, the resource
location you choose would be the closest one to the US region.

Additional Resources:
• What are resource locations? - https://docs.citrix.com/en-us/citrix-cloud/citrix-cloud-resource-
locations/resource-locations.html

48 © 2020 Citrix | Confidential

Key Notes:
• Zones in Cloud Studio are bonded with resource locations. Using Zones you can map Cloud Connectors, Machine
Catalogs, Host Connections, Users and Application groups to a particular Resource Location.
• On-premises Virtual Desktops has a Primary Zone (which has the Site Database) and may have a Satellite Zone. VDAs
in a Satellite Zone register with the Delivery Controller in a the same Zone. If a Controller in a Satellite Zone fails, it fails
over to another local Controller, if possible. If no local Controllers are available, it fails over to a Controller in the Primary

© 2020 Citrix | Confidential

 Zone.
• In a Citrix Virtual Apps and Desktops Services Site there is no Primary Zone because the Database and
Delivery Controllers reside in Citrix Cloud and not inside the resource location.
• For each resource location created in the Cloud Control Plane, a corresponding Zone is created inside Cloud
Studio.
• Zones are managed through the Zones section in Cloud Studio.
• When creating new resources such as machine catalogs, hypervisors, host connections and applications
you specify which zone and resource location they will be hosted in.
• Placing items in a zone affects how the service interacts with them and with other objects related to them.
• When a hypervisor connection is placed in a zone, it is assumed that all the hypervisors managed through
that connection also reside in that zone.
• When a machine catalog is placed in a zone, it is assumed that all VDAs in the catalog are in the zone.
• Citrix Gateway instances can be added to zones. When you create a resource location, you are offered
the option to add a Citrix Gateway. When a Citrix Gateway is associated with a zone, it is preferred for
use when connections to VDAs in that zone are used.
• Ideally, Citrix Gateway in a zone is used for user connections coming into that zone from other zones or
external locations, although you can use it for connections within the zone.
• After you create more resource locations and install Cloud Connectors in them (which automatically
creates more zones), you can move resources between zones. This flexibility comes with the risk of
separating items that work best in close proximity. For example, moving a catalog to a different zone than
the connection (host) that creates the machines in the catalog, can affect performance. So, consider
potential unintended effects before moving items between zones. Keep a catalog and the host connection
it uses in the same zone.

Additional Resources:
• Zones in Citrix Cloud - https://docs.citrix.com/en-us/xenapp-and-xendesktop/service/manage-
deployment/zones.html

49 © 2020 Citrix | Confidential

Key Notes:
• On-premises Citrix Virtual Apps and Desktops site has Delivery Controller, Citrix Studio, Citrix Director, Citrix License
Server, the Database and VDA within the customers’ datacenter.
• The maintenance and upgrade of all these components have to be done by the Citrix administrators.
• To support the Citrix infrastructure, the administrators need to have proficient knowledge of bare metal hypervisors
(Hyper-V, ESXI or Citrix Hypervisor) in order to set up a compute layer.

© 2020 Citrix | Confidential

 • If the users are remotely connecting then the Citrix ADC and Firewalls also have to be configured and
maintained by the IT administrators.
• This leaves the IT team with many components to setup, configure and upgrade, hence reducing their
productivity.

50 © 2020 Citrix | Confidential

CCI Talking Points:
• When you present this slide, switch back to the previous slide to show that it’s the same deployment, just done in a
public cloud instead of on-premises.

Key Notes:
• The Forklift model refers to deploying all of the Citrix Components in a public cloud.

© 2020 Citrix | Confidential

 • The Forklift model saves the efforts to setup and maintain a private data center. In this, the patching and
upgrade of the underlying hypervisor is done by the cloud vendor.
• This also offloads the security considerations and practices to the cloud vendor, allowing the IT administrator
to focus on the application development, user data and remote delivery of resources.
• The perpetual licenses used in an on-premises deployment can be re-used in a cloud forklift model.
• Some cloud vendors operate as Citrix Service Providers and use this deployment method to sell SAAS.
• Note: CSPs have access to special license programs for the same purpose.

51 © 2020 Citrix | Confidential

CCI Talking Points:
• Explain to students that by moving to Citrix Cloud, they no longer need to maintain their Delivery Controllers or worry
about their site databases. Nor do they need costly SQL licenses to host the Site databases.

Key Notes:
• With the Citrix Virtual Apps and Desktops Service in Citrix Cloud the Delivery Controller, Citrix Studio, Citrix Director,

© 2020 Citrix | Confidential

 Citrix License Server, and the Database are maintained and managed by Citrix. Collectively, they make up
the Control Plane of the Citrix Virtual Apps and Desktops.
• The VDAs are left within the customers’ datacenter. These are managed by the Customer or Citrix Partners.
• The Cloud Connectors are also hosted in the customers datacenter. However, they are managed and
updated by Citrix Cloud.
• Workspace and Citrix ADC can be hosted either in Citrix Cloud or StoreFront and Citrix ADC can be
deployed within the resource location.
• A customer can also chose to use workspace in Citrix Cloud and route the HDX connections through on-
premises Citrix ADCs.
• In such a deployment, the customers’ IT team will have to maintain:
• Compute layer: Hypervisor, Networks, Storage and Memory.
• Remote Access Solution (Optional) : If users are connecting remotely.
• Business Critical Applications and their databases
• VDA software installed on Servers or Desktops within the resource location.
• AD, Printing and other non-Citrix components.
• The customers’ datacenter hosting the Citrix VDAs is referred to as a resource location in Citrix Cloud
Terminology.
• The Control Plane is managed by Citrix. However, the configuration of Policies, Machine Catalogs and
Delivery Groups are the customers’ responsibility. Also, these configurations are very similar to an on-
premises Citrix Virtual Apps and Desktops site configurations.
• In addition to the standard supported hypervisors, such as Citrix Hypervisor, vSphere and SCVMM/HyperV,
customers can also deploy resources to CloudStack and Nutanix Acropolis.

52 © 2020 Citrix | Confidential

Key Notes:
• The workloads aka the VDAs can also reside in a public cloud.
• Using public cloud as a resource location to host resources helps to offload the compute layer setup and
maintenance to a public cloud vendor so that the internal IT can focus on business critical applications and securing
the mission critical data.
• Public clouds vendors offer 99.9 % of uptime, which is very tough for any private data center to achieve.

© 2020 Citrix | Confidential

 • Also, public clouds are built using industry leading practices and strict security guidelines.
• Building such a stable and secure compute layer on a private data center requires a massive skillset
and investment.
Using the public cloud helps in reducing the capacity expenditure and provides agility to expand on
demand as per business needs.
• When customers opt for Citrix Virtual Apps and Desktops Service with Public cloud, they essentially have to
configure and maintain only the workloads (aka VDAs). The rest of the components of Citrix Virtual Apps and
Desktops are maintained, secured, backed up and upgraded by Citrix. Similarly, the compute layer
resources are managed by other cloud vendors like Microsoft or Amazon.

53 © 2020 Citrix | Confidential

CCI Talking Points:
• Remind students that they can deploy to as many resource locations as we want with Citrix Clouds, and those
resource locations can be a mix of on-premises and the supported public clouds.

Key Notes:
• Many companies prefer to keep mission critical data on a private datacenter and, hence, cannot move to a public

© 2020 Citrix | Confidential

 cloud entirely. In such scenarios, it is preferable to keep critical applications and their databases on a private
datacenter owned and managed by the customers themselves. The remaining applications are moved to a
public cloud, thus leveraging the benefits of both public and private cloud. Such a setup is referred to as the
Hybrid cloud.

54 © 2020 Citrix | Confidential

CCI Talking Points:
• Instruct the students to initiate the provisioning of their labs, but not to wait for provisioning to complete.
• It should take about five minutes, which should be enough time to complete the lecture of the next lesson.

Key Notes:
• If needed, please refer back to Module 0 for reference on how to access the Lab.

© 2020 Citrix | Confidential

 • Do not wait for the labs to fully provision, just initiate the provisioning. The lab should finish provisioning in time
to start the lab exercises.

55 © 2020 Citrix | Confidential

CCI Talking Points:
• Walk the students through the unique benefits of Citrix Cloud and present each bullet.
• Delegated Administration is not as extensive in Citrix Cloud, but more granularity is being added in future releases.

Key Notes:
• HA: Citrix Cloud has been designed for high availability for each customer, every component is load balanced and many

© 2020 Citrix | Confidential

 components are available from different regions.
• Citrix Cloud is built in a public cloud, and all the VMs and data is replicated amongst different sites and
storage zones.
• GSLB: The Citrix ADC architecture running Citrix Cloud is built with Global Server Load Balancing in mind.
• Single Site: In Citrix Cloud a customer only has a single Site, all VDAs, Catalogs, Delivery Groups, Citrix
ADCs (and etcetera) are defined in Zones / resource locations.
• Zones are not parent/child like with on-premises deployments.
• Site databases: The Site databases are hosted by Citrix Cloud.
• The customer does not have to worry about maintaining and operating the databases. Because Delivery
Controllers are only deployed within Citrix Cloud and each resource location has Cloud Connectors, the
latency and bandwidth concerns between different datacenters are not as important.

56 © 2020 Citrix | Confidential

Key Notes:
• Citrix Cloud Control Plane Ownership:
• The Control plane includes the components that are setup, maintained and backed-up by Citrix.
• It includes: Delivery Controllers, Databases, Citrix Studio, and Citrix Director.
• Citrix also provides a preconfigured Workspace Store to access the published resources, but the choice to use cloud-
hosted Workspace or an on-premises StoreFront is left with the customer.

© 2020 Citrix | Confidential

 • Similarly, to provide remote access, customers can either use the cloud hosted Citrix Gateway as a Service
acting as an ICA proxy only or use an on-premises Citrix ADC.
• Citrix Cloud Infrastructure Ownership:
• Citrix provides 99.9% uptime on its Cloud Services.
• The status of the Citrix Cloud Services can be monitored from http://status.cloud.com/.
• The control plane of Citrix Cloud Services resides in public clouds with multiple datacenters across the
globe.
• The backend architecture details of Citrix Cloud are not disclosed to maintain security and integrity of the
cloud services.
• Google Cloud is not supported from an MCS or hosting integration perspective.
• However, VDAs can be deployed without image and power management.
• Citrix Cloud VDA Ownership:
• VDAs are workloads where customers install their business specific applications.
• These workloads are managed by the customers in on-premises datacenters or public cloud solutions.
• If customers subscribe for Secure Browser service that provides simple and secure remote access to web
applications, then the VDAs are also maintained by Citrix.

57 © 2020 Citrix | Confidential

© 2020 Citrix | Confidential
© 2020 Citrix | Confidential
CCI Talking Points:
• There are 7 lab exercises in Module 4; this slide addresses 2 of them.
• This Slide:
• 4-1 Create a Machine Catalog for Multi-session OS (Server OS) using MCS
• Time: 17 minutes
• 4-2 Create a Delivery Group for Server OS

© 2020 Citrix | Confidential

 • Time: 6 minutes
• 4-3 Create Machine Catalog for Single-session OS (Desktop OS) using MCS
• Time: 6 minutes
• 4-4 Create Delivery Group for Desktop OS
• Time: 3 minutes
• 4-5 Update a Machine Catalog for Single-session OS (Desktop OS)
• Time: 16 minutes

60 © 2020 Citrix | Confidential

© 2020 Citrix | Confidential
© 2020 Citrix | Confidential